Re: [Chicken-users] Reading from TCP sockets and time outs

[Kim]

On 2004-04-11 15:20:47 +0200 (Sun), felix (address@hidden) wrote:
[snip]
> 
> Yes, the threading stuff in Chicken is more designed towards being
> simple and SRFI-18 compliant, instead having a clean and general
> API for doing blocking/unblocking. Currently a thread can either
> block on timeout, on I/O or on termination of another thread.
> Blocking for timeout can be combined with blocking for termination
> (incidentally). messages (i.e. mailboxes) work by solely using
> thread-suspend!/-resume!.

Greetings again --

Well, I *think* I've got it working by having a thread block with both
 ##sys#thread-block-for-i/o and  ##sys#thread-block-for-timeout on a
single thread, then, when a message arrives, using ##sys#thread-unlock-thread
to wake up the waiting thread, which then checks to see what caused it to
get woken up.  On the face of it, it appears to be working so far.

 
> I will try to find a solution for this problem (blocking on TO, I/O and
> messages). If you would have any ideas for a decent API, please tell.

Actually, I initially tried to write it as a generic API and got stumped.

I suspect some sort of limitations have to be applied, but I am not sure
what would be the best/most reasonable way to do it -- I can understand
why the PLT Scheme's 'read waitable' returns the data read from the
socket it is waiting on, for instance, instead of just a 'Ready to be
read from' signal.  If you have multiple threads waiting on a input
port, and it becomes available, how should it be handled?  If you wake
up all waiting threads, then they have to fight/arrange among themselves
for who gets to read the data.  If you wake up only one thread, it needs
to read the data immediately/before whatever monitoring system for the
socket runs through another loop, sees the socket is ready to be read
from, and wakes up the next thread.  

By instead of returning "ready to be read from" indication by returning
the data read from the socket instead, PLT solves much of the problme.
I'm betting that, when data is ready to be read from an input port,
they read it first, then wake up the first thread waiting on it, return
the data to it, then return to waiting -- this clears the socket status
immediately instead of waiting for a woken up thread to get around to
doing something about it.

It`s not a bad approach, but it does mean the input gets arbitrarily
chopped up before it reaches any threads to process it.  The 
alternative, which I am sort of leaning towards, is to say that only
one thread can monitor a port at a time.  

Hmmm... a completely different API might be something closer to
wrapping a port with a mutex, such that only one threads at a time
could 'hold' the port.  

So, something like:
 (set! x (mutex-or-lock! timeout-num-or-#f a-mutex-here a-wrapped-port ...))
 (cond 
   ((not x) ;; time out ... )
   ((eq? x a-mutex-here) 
     ;; got mutex, do protected stuff 
     (mutex-unlock! a-mutex-here))
   ((eq? x a-wrapped-port) 
     ;; got exclusive access to the port, which is ready to be used
     ;; read stuff from port until satisfied
     (mutex-unlock! a-wrapped-port)))

This might also be useful for:
  (mutex-or-lock! timeout-num-or-#f mailbox-1-mutex mailbox-2-mutex ...)

And for something like:
  (define (write-to-common output)
    ...
    (mutex-lock! wrapped-output-port)
    ;; Exclusive access to the output port 
    ;; can safely write out long block of data without 
    ;; worring about another thread interleving output with it
    (mutex-unlock! wrapped-output-port)
    ...
  )
    

Just some thoughts -- I'm not knowlegable enough about the internals
or direction Chicken is heading enough to make more than hesitant 
suggestions for ideas.  

Kim

-- 
Kim      address@hidden                 http://solluna.org/
"Nothing in the world is more dangerous than a sincere ignorance 
and conscientious stupidity" - Martin Luther King, Jr.