Hi Alex,
> 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.
yes, indeed.
I attach a simple non-blo
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.
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
a
Aarrgh ...
Sorry, this was complete nonsense!
I get into a busy waiting loop with that.
I have to change it back, the old version was correct.
Sorry for the confusion,
- Alex
--
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
On Thu, Oct 09, 2008 at 11:03:06AM +0200, Alexander Burger wrote:
> I'll try this out soon. It will probably involve only the removal of the
>
> blocking(YES, ex, sd2);
>
> calls in "src/net.c", and additional checks for EAGAIN after some read()
> calls. Does anybody see a problem with t
Yes, Wiki's can be quite useful.
Getting a copy of the standard reference documentation on there would
be useful. Then we could all work on expanind it a little as the
current desciptions are quite terse in places.
Granted the fact that we have readable documentation at all is a great
boon, and a
On Thu, Oct 09, 2008 at 08:12:28AM +0200, Alexander Burger wrote:
>Under Linux, select() may report a socket file descriptor as "ready
>for reading", while nevertheless a subsequent read blocks. This could
>for example happen when data has arrived but upon examination has
>wrong che
