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.
--
Steve
|