It's an IPC protocol stack I wrote that can handle and switch between syncroneous, threaded and asynchroneous.
It seems simle to read the data before calling though, both read and read_callback could use the same buffer and read_callback could be avoided to be called if the buffer is empty?
Ie,
poll(..)
foreach (fd_with_read_set,fd) fd->buffer+=fd->read_some();
foreach (fd_with_read_set,fd) if (sizeof(fd->buffer)) { string buf=fd->empty_buffer(); fd->read_callback(buf); }
...
fd::read(...) { string data=fd->empty_buffer(); ... read() }
Does the opposite problem exist, calling write_callback on a blocking buffer that's been filled by another thread?
/ Mirar
Previous text:
2003-03-19 23:48: Subject: I/O callbacks in blocking mode
/.../ or that Pike loops over every socket that made poll exit until it calls poll again (which is a good idea, generally?).
That's probably it, judging from your comment at the start of __stdio_read_callback. I see two ways to solve it without resorting to peeking, which apparently is slow:
- Read out the data from all the fds before calling any callbacks.
- Read out the data from one of the fds and do the equivalent of read(0,1) on all the others, then call the callback for the one fd only.
The first solution can have tricky compatibility effects in code that reads on an fd from the read callback of another; it will no longer get any data since it has been read already. Otoh, it seems very precarious to write such code. Do you remember where you came across it?
/ Martin Stjernholm, Roxen IS