Re: [Twisted-Python] new function for t.i.main
On Tue, 7 Aug 2001, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Daemonize's functionality is probably useful, however, there are a few things it doesn't take into account. Insofar as it's useful, most of twistd should probably be incorporated into it; any less is offering incomplete functionality.
No it isn't. It's offering *just* the daemonize functionality. You can have a higher-level wrapper *on top* of that which is portable, but daemonize() is useful.
After all, this is about as platform specific as you get.
Yes it is. I firmly believe in platform-specific APIs which are then wrapped in platform independent APIs. I don't want anything to restrict my access to the OS
If we have daemonize, then we probably want to have a similiar function for starting a Windows Service.
Yes, it would. This isn't an argument against daemonize.
Moreover, it would be good if we could detect which platform we're on, then do the appropriate thing for creating a daemon on that platform.
Agreed. But not with daemonize() -- with startService(....) which would call daemonize() on UNIX.
This implies logging. "daemonize" won't work if you're still writing to standard output after you call it.
Well, it closes FD 1, so it works well enough for that. Logging is left for a higher level API. As is writing PID files (which must be done after daemonizing but before getting into the main loop)
So I'd say daemonize should at least take a logfile, and a function + varargs, and never return.
No, that's startService, another useful API.
This sounds cool, with one minor caveat.
I don't want to give windows users the impression that they're totally unsupported, especially any more than they already are.
Fine, support them ;-)
We should make plans to have similiar windows-ize scripts, and even if we don't have them, make it clear that we're not trying to make a debian-specific server infrastructure.
*I* don't care if my server infrastructure is Debian specific.
Also, wouldn't this "debian" functionality be very similiar for redhat, mandrake, etc? Even solaris and MacOS X? "unixize" might be a better name for it.
No. Debian uses .deb packages. Maybe whoever does RPM chooses to redhatize or rpmize (I'm not sure: would she support SuSE? Mandrake?) Solaris uses its own unique wonderful format, as does MacOS X and AIX. I would be happy to put my /etc/init.d/ templates where everyone can use them. Everything else is distribution specific. It's not hard to have a hand install of a .tap if you have the /etc/init.d template. I want the Debian packages to be good enough that I'll feel good enough about uploading them to the official Debian archive, as well as maintainig a huge apt source on tm.com. -- Moshe Zadka - http://moshez.geek (if you're not cool, http://moshez.org is still working)
On Wed, 8 Aug 2001, Moshe Zadka wrote:
On Tue, 7 Aug 2001, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
any less is offering incomplete functionality.
No it isn't. It's offering *just* the daemonize functionality. You can have a higher-level wrapper *on top* of that which is portable, but daemonize() is useful.
Sorry, no. If you don't redirect stdout properly, your daemon is broken, unix or no.
Moreover, it would be good if we could detect [...]
Agreed. But not with daemonize() -- with startService(....) which would call daemonize() on UNIX.
Yes. And it should be strongly deprecated to call daemonize directly.
So I'd say daemonize should at least take a logfile, and a function + varargs, and never return.
No, that's startService, another useful API.
I would argue that daemonize is not useful without this API. It's sufficiently small that everyone who wants to write UNIX-specific servers has to know about it anyway; and if they don't want to know about those sorts of things they ought to use the cross-platform API.
*I* don't care if my server infrastructure is Debian specific.
Yes, and it's people like you that I'm trying to protect users from :-) What additional _semantics_ does unix 'daemonize' provide that a cross-platform startBackgroundServer() doesn't? Do you really need the extra 40-odd bytes of stack space for the Python frame that you're losing by having a call-through approach rather than returning? All it really lets you do is write servers that require a programmer to run on Windows. If there's no good reason for that, it's silly. For example, although the 'process' object doesn't currently run on Windows, its external API just relies on the notion of a process which can be written to and read from as a file. Once Jürgen finally writes that cgi-for-nt implementation he was talking about many months ago, I'm sure it'll work fine on that platform ;-).
I want the Debian packages to be good enough that I'll feel good enough about uploading them to the official Debian archive, as well as maintainig a huge apt source on tm.com.
Well, I definitely support your desire for high quality. However, what's this about a "huge apt source on tm.com"? ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
On Wed, 8 Aug 2001, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Sorry, no. If you don't redirect stdout properly, your daemon is broken, unix or no.
I'm willing to compromise on the stdout issue. The loop issue isn't about stack space - it's about doing stuff between the daemonizing and the looping without writing another function. The classical example is daemonize(logfile) open(pidfile, 'w').write(str(os.getpid())) app.run()
Yes. And it should be strongly deprecated to call daemonize directly.
Why? Even if I'm writing something UNIX specific?
I would argue that daemonize is not useful without this API.
And that would be akin to argue that fork() is not useful without spawn(). The fork/exec in UNIX has been shown to be very powerful.
It's sufficiently small that everyone who wants to write UNIX-specific servers has to know about it anyway; and if they don't want to know about those sorts of things they ought to use the cross-platform API.
But knowing and "writing it 10 times" is different. Especially, "and the 8th time, use stdout.close() instead of os.close(1)".
*I* don't care if my server infrastructure is Debian specific.
Yes, and it's people like you that I'm trying to protect users from :-)
I'm not writing unportable code intentionally. I just don't care about more portability which degrades quality. Like not using fork() because it's not portable. That sentence was written about why I want a --debianize option to mktap. You took it out of context.
All it really lets you do is write servers that require a programmer to run on Windows. If there's no good reason for that, it's silly.
It lets me have convenience in return for portability to a system nobody I really care about runs.
For example, although the 'process' object doesn't currently run on Windows, its external API just relies on the notion of a process which can be written to and read from as a file. Once J=FCrgen finally writes that cgi-for-nt implementation he was talking about many months ago, I'm sure it'll work fine on that platform ;-).
Sure, and that's a great abstraction -- for those who want to use it. You would not argue that this means that twisted programs cannot use fork(), right?
Well, I definitely support your desire for high quality. However, what's this about a "huge apt source on tm.com"?
PArtly a joke, partly a vision for a world where everybody uploads packages into tm.com/apt, and then just "apt-get install integrated-web-and-mail-server" will work. -- Moshe Zadka - http://moshez.geek (if you're not cool, http://moshez.org is still working)
participants (2)
-
Glyph Lefkowitz -
Moshe Zadka