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

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.

- Alex

Reply via email to