[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jan 15 12:11:38 2003 
Subject:sys_async_io Problem 
From:steve 
Volume-ID:1030115.04 

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