Steve,
here's an immediate but brief response - I'll try and find time to look
closer soon. Back in the dawn of time (when sockets were new and
completely unknown territory for poplog) I used to try and use SIG_IO
to do exactly this kind of thing, and used to run itno problems which
sound very much like the ones you describe. Unfortunately I can't recall
now whether we actually worked out why, though I have a vague
recollection it was an interaction with the process being in a wait
state on another device (including standard input). I quite quickly
moved away from SIG_IO completely and used a select-based interface
which is more reliable, but requires coordination between all the
devices you want to wait for. Much later support for that went into the
system under the name of sys_device_wait. but it never got in there
deeply enough I don't think - ideally you should be able to just attach
devices to whatever the system might currently be waiting for (like
standard input), but you can't. Indeed, most X-based application sit in
a select all the time they aren't doing anythign else, but Poplog X
can't do this, so it polls the X socket connection periodically (10
times a second?) to see if there's any work to do. You may well have
more luck trying the same thing - set a timer and use sys_device_wait to
poll (ie with wait argument false) the devices you are interested in
every so often.
Roger
Stephen Leach wrote:
> Hi,
>
> BACKGROUND
>
> I've got an urgent problem that I would really appreciate some help with.
>
> I am developing a next generation web server in Poplog/Linux. It
> relies heavily on the use of signals to respond to requests. In
> particular, it uses sys_async_io with socket-devices to respond to
> incoming requests on a particular set of ports. And I've got
> intermittent failures to respond to HTTP requests on these sockets.
>
> (It is fairly clear to me that this is not a well-exercised area of
> Poplog. The API is under-documented and too sparse. See the tail-end
> of this message for examples of what I mean. So it isn't too much of
> a surprise to run into a tricky problem and not know the cause.)
>
>
> THE PROBLEM
>
> I set up the server with assignments like this
>
> ;;; 0 = on input ready, see REF sys_async_io and REF sys_device_wait
> start_http_handler(% control_sock %) -> sys_async_io(
> control_sock, 0 );
>
> which means that when there is input ready on the control-socket it
> should run the http_handler code. This in turn binds the socket as
> follows
>
> ;;; false = org, see REF sysio
> sys_socket_accept( control_sock, false ) -> comm_sock;
> ;;; 0 = on input ready
> http_handler -> sys_async_io( comm_sock, 0 );
>
> Unpredictably, but frequently, my control sockets get stuck in a
> "wait" state when I submit a request from a web browser. When I
> inspect the offending control socket, using sys_input_waiting, it
> returns 0. i.e. it is waiting for input to be read off them but have
> no bytes in the buffer. This is just what one might expect - except
> that the start_http_handler should run immediately and clear the state.
>
> This seems to indicate that, somehow, the signal handler is not
> running normally. Why? Have other people seen this before?
>
> I am running XVed, so it is handling X-events OK. The system is idle
> apart from the incoming request.
>
> I have set some signal processing conditions, though. In particular,
> I have set the sys_signal_flag of SIG_IO as follows
>
> { ^SIG_IO ^SIG_USER_XXX ^SIG_USER_YYY } -> sys_signal_flag( SIG_IO )
>
> where SIG_USER_XXX and SIG_USER_YYY are user defined signals created
> assigning to sys_max_signal. Maybe this is a problem?
>
> I would be very grateful for any opinions or accounts of similar
> experiences.
>
>
>
> EXAMPLES OF UNDER-DOCUMENTATION AND UNDER-DEVELOPMENT OF SIGNALS API
>
> Here are a couple of examples of how inadequate socket/signal support
> is in Poplog. I sincerely hope that I am wrong in my assertions and
> that people can point out what I have missed. I put this in for
> general interest.
>
> As an example of under-documentation, it is not at all clear how a
> listening socket will respond to an incoming request - will it signal
> input ready, output ready, or out-of-band ready? And once that socket
> is bound, it isn't clear whether or not this will clear the
> ready-condition. [The answer turns out to be that the listening
> socket signals "ready for input" and binding the socket clears this
> condition.]
>
> The most painful area of under-development is the lack of inspection
> facilities. For example, I cannot find any way to iterate over all
> the sys_async_io entries. The same is true of sys_timer.
>
> Another problem seems to be that sys_async_io is implemented by some
> kind of "temporary" property. Which means that if a garbage
> collection happens, an idle listener simply gets garbage collected. It
> took me several hours to realize that I couldn't simply assign to
> sys_async_io. I also had to implement a "clean-up-on-device-closed"
> procedure.
>
> Also, there appears to be no way to log the signals that Poplog is
> responding to. It would be really nice to be able to turn on/off a
> (limited-size) buffer that records the events so you can debug a
> signal-based application.
>
|