Does the opposite problem exist, calling write_callback on a blocking buffer that's been filled by another thread?
I suppose so, but that can't be helped in all cases. The difference is that the read case will hang the backend before the user callback is even called, which makes the hang "internal". However, the write case should have a similar flag as you've suggested for read, so that Pike at least can guarantee that there's write buffer available at the moment when the write callback is called.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-03-20 08:10: Subject: I/O callbacks in blocking mode
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