Re: Looking for implementation idea

[Thomas Handler <thandler@systems.at>]

Paul,

thank you for your reply.

Paul Duquennoy wrote:
 
> I did something like that few years ago. I designed one dispatcher task that
> did OS_select to get the available data and wad responsible to get full
> messages (i.e.handle one buffer per socket where the message bytes where
> stored until a full message was obtained). It then had a rendez-vous with a
> task from a task array whose index was the socket number. These tasks were
> generating one answer for each message, so the dispatcher task, which was
> also in charge of the writes, could know if some work was in progress in the
> software by the difference between input message count and output message
> count. If work was in progress, the OS_select was with a null time-out and a
> delay was used. If no work was in progress, the OS_select could use an
> appropriate time-out.

This approach is interesting, I didn't think of it that way. But as far
as I can see I have still one problem left:
If the underlying task lib doesn't block on OS calls (i.e. when using
LinuxThreads) it would be possible that obe of them would do some
processing at the time the dispatcher checks if there is some work to
do. So the counter is 0 and the dispatcher uses a timeout - the next
moment the worker task finishes its calculation and wants to do IO...

Anyway I got another piece for my puzzle ;-)

Ciao,
  Thomas Handler