Hi Alex,

that sends me back to the drawing board a little. Yet again I recall
seeing the fifo function but didn't realise I might need it : )

A few other things occured to me as I was working on this on the
train. The task and *Run mechanism (if used with enough care) give us
non blocking reads.

But the underlying select function also provides non blocking writes.
so that you can dely trying to write to a socket until it is ready for
more data.

It would appear that task and *Run have no way of using this part of
the select function.

There is also out of band data as a thrid set of descriptors however
all the documentation suggests that this is rarely used unless you are
doing particularly low level magic.

regards

Konrad.

2008/10/10 Alexander Burger <[EMAIL PROTECTED]>:
> Hi all,
>
>> Sorry for the confusion,
>
> Let me try to explain the situation:
>
> In the present system, it does not help at all to put the socket into
> non-blocking mode. The reason is that select() is conceptionally
> separated from read().
>
> After select() signals (correctly or incorrectly) that data are
> available, the corresponding task's body is executed. It will try to
> read from that socket, and from that moment there is no way back. When
> no data at all arrive, or only a few bytes but not the complete message,
> it has to wait until the full message is assembled, be it blocking or
> non-blocking.
>
> Even if select() would be accurate, and never send an event to the tasks
> unless there are really data available, it would not help because there
> might be less data available than are needed for the full message, and
> the missing data might never arrive.
>
>
> So if you need to do such things asynchronously, the whole process of
> assembling the message - probably byte by byte - has to be put into a
> separate task. And you need a timeout for that task, too, because it may
> well be that the message will never be completed. The timeout should
> abort that task and close the connection.
>
> In this case, a non-blocking mode might be helpful, as in cases where
> select() wrongly said that data are available will not block the system,
> but most probably in those cases the data will arrive a few milliseconds
> later anyway (when the TCP stack resends the packet), or the connection
> will close down (sending EOF to the task), and processing will resume.
> Only in the - very few - remaining cases, the timeout will fire and have
> to cleanup the task and its connection.
>
> The drawback of implementing such a fully non-blocking system will be
> that the present separation of event generation (select) and data
> processing (read) cannot be held up any longer, and a completely
> different application flow is required.
>
>
> Therefore, I would go with the current solution, collect the messages in
> the task's body character by character (or even byte by byte), and
> implement a decent timeout for the pathological cases where this message
> assembly gets stuck for whatever reason. The collection of those pieces
> in the background might be done nicely with the 'fifo' function, keeping
> a first-in, first-out list for each task, and some supervisor logic in a
> higher layer checks those queues for messages, and retrieves and
> executes them.
>
> Just my two yen.
>
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
>
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Reply via email to