Re: [Chicken-users] How to avoid busy waiting when using tcp-accept and threads?

[Joerg F. Wittenberger]

Sven Hartrumpf <address@hidden> writes:

> Hi.
> 
> I have a server program that serves client requests in parallel using
> chicken threads. The main structure of the server is given below.
> Currently, even before the first request comes in, the server needs 100%
> cpu time. The server is the only thread at that time and stays in the

To me it looks as if there is a glitch in the scheduler code.  While
you code sits busy wainting, the scheduler would do the same, if there
where only blocked threads.

Maybe I'm missing something.  Do I?  Otherwise I'd suggest that
select(2) should be called with a non-zero timeout value, if there is
no thread to ready to run.  The timeout value should be exactly until
the next real time event (threads-sleep!) is due, which then should be
delivered.

> > chicken threads. The main structure of the server is given below.
> > Currently, even before the first request comes in, the server needs 100%
> > cpu time. The server is the only thread at that time and stays in the
> > first part of the loop because tcp-accept-ready? returns #f. This is
> > as intended, but how can I avoid this busy waiting?
> >
> 
> 
> Currently not. tcp-accept is non-blocking exactly because we want
> other threads to run.
> 
> But perhaps we can add a little hack: if no other threads are running
> *or* blocked for timeout/input, we can do a blocking accept().
> 
> Would this work?

this is actually confusing to me.  tcp.scm claims:

;   (tcp-accept LISTENER) -> IN, OUT
;     Waits until a connection is established on the given listener
;     and returns inout- and output-ports for the connection.

and the code reads:

      (##sys#thread-block-for-i/o! (current-thread) (##sys#slot tcpl 1) #t)

I also would think the whole magic with the (tcp-accept-ready?
server-socket) in Sven's code is not actually required.  The http
example from Felix doesn't use it either.

Did anybody get any multithreaded server code already running with
tcp.scm?  I'd appreciate an example.

Best regards

/Jörg

-- 
The worst of harm may often result from the best of intentions.