> Restarting is a little tricky for multi-threaded processes; you need
> to leave any active threads running until they complete, without
> making their symbols disappear out from under them. The approach I
> use is to fork1(2) from inside the accepting thread, with the parent
> closing the accept socket and thr_exit(2) and with the child duping
> the handle onto stdin, and re-execing the daemon with an argument
> telling it to use stdin as the socket to accept on. This can add a
> little delay to the processing of pending connections, but is the
> only way I've found to avoid the possiblity of losing connections.
Hmm... This sounds very Sun specific (I'd be interesting in doing
this on SGI's IRIX 5, which has dynamic linking like SunOS but a
different thread library).
> There is no client at this stage; this is all handled at startup time.
Then maybe I didn't understand your story about restarting... How do
you actually tell your server to restart?
> The contents of the cookie are undefined; it's up to the module what it
> keeps or discards.
My point whas that the mount point argument is unnecessary here. Do
you not agree?
> Yes. A return of zero means the handler either succeeded or failed
> :-) It also means that the server shouldn't bother trying to
> generate an error message. A result of 200 means that the handler
> definitely succeeded, and the transaction is complete; a result of
> anything else means an error definitely occured and that the module
> should generate an error message for the client.
What's the point of having two return codes? Why not simply specify
"0 -- request completed; anything else -- generate HTTP error code".
> The handlers are all running multi-threaded; the library doesn't currently
> export any synchronisation primitives, although the modules themselves are
> free to use any services the host system supports. It might be worth adding
> some wrapper functions to the library to make code easier to port.
We have a simplified thread interface which is ported both to SGI and
SunOS 4 and 5 and maybe other systems; it may be a starting point for
portable synch primitives. Interested?
> Yes, and yes. http_error generates a response, and produces an error message.
> The header for the response specifies "Content-Type: text/html", but does
> not include a "Content-Length:" field.
You may be sorry for the Content-Type: text/html header in the future
-- I'd say just write the response header. Then I can also use it to
generate a 200 response.
> Any extra data sent to the socket must be valid html code; the module can
> rely on the html document being at the start of a paragraph.
Oops, do I understand correctly that you already generate some HTML
describing the error?
> >(Actually, at supposedly little cost, can't you use stdio instead of a
> >raw socket? Usi fdopen(sock, "r") to open a FILE and then you can
> >just use fgets() to read the next line if you really want to parse
>
> That's a possiblity which I thought about; ther lose with fgets is that it
> copies data from the buffer into the passed-in argument. There is also some
> lossage when using stdio streams in bi-directional mode. Also, since
> the file zapper works by mapping the file, and then calling write with
> the ptr to the mapped file, I don't want stdio even thinking about copying
> the data into its buffer.
You can't use stdio streams in bi-directional mode, but you could
fdopen() two files, one for reading and one for writing. For the file
zapper, simply fflush() the stdio file and to a write() to its
fileno() -- this is well-defined according to Posix and I'm sure also
in practice. Doing everything using stdio will pay in the future when
useful handlers are ported to systems that don't support sockets (or
have weird sockets, like NT).
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>