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]
