Solaris threads are UI compliant, which is very similar to pthreads;
however the actualy mechanics of restarting a server isn't specified
as part of BGI.
>Then maybe I didn't understand your story about restarting... How do
>you actually tell your server to restart?
I use the standard convention of 'kill -HUP pid' to request a restart. However,
that's just me :-)
>
>My point whas that the mount point argument is unnecessary here. Do
>you not agree?
It may or may not be necessary; the spec could be changed to drop it
and force the cookie to hold the mount_point if the handler wants it.
I'm easy either way..
>
>What's the point of having two return codes? Why not simply specify
>"0 -- request completed; anything else -- generate HTTP error code".
Just othogonality; 200 is the code for OK in http, so I thought I might as
well allow an application to signal unambiguous success. Again, it's not
something I'm particularly attached to, but it seemed a good idea at the time.
>
>SunOS 4 and 5 and maybe other systems; it may be a starting point for
>portable synch primitives. Interested?
I have an application framework that I wrote to hit thread details;
I've only implemented it for UI threads so far, although I did have a try
at a posix module - unfortunately, I don't have a machine that supports
kernel level posix threads, so I haven't integrated it into the main-line
code.
>
>> 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.
I have a separate function which I use to generate 200 headers, which fills
in all the usual stuff; however, since I'm not yet satisfied with it, I
didn't add it to this version of the spec.
>
>> 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?
Yes; the aim is to generate generic error descriptions in the library.
At the moment I haven't properly coded this part, and just have a standard
message ("Error %d - it's buggered, lad"); this will be replaced by something
more useful real soon now. I will probably be adding another paramater to
http_error which would be a pointer to the accept_language variable. However
this won't happen properly until I get a bigger collection of internationalised
error messages (like, for example, Dutch :-)
Simon