Hi! On Wed, Mar 22, 2006 at 04:30:28PM +0100, Jan Engelhardt wrote: >>> How could I help the high CPU usage then? The device driver read >>> routine always prematurely exits because IO_NDELAY is set (and >>> there's nothing to read - so EWOULDBLOCK is returned).
Which device do you use? Does that not support poll/select/kqueue properly? Because if it did, the pthread library would probably do the right thing (on EWOULDBLOCK, suspend the thread, and sometimes use kqueue or similar to find out when it can re-schedule the thread again). >>the real syscall symbols are available as _thread_sys_read and so on. >>you'll also need to clear non-blocking with _thread_sys_fcntl. >If I would now use _thread_sys_read and so on, then the main thread >would block (as expected), but due to the implementation, control is >not passed to other threads (because of blocking on _thread_sys_read()) >as far as I understand. >It looks like I am not able to do threading and blocking at the same >time, that's where I am stuck. I've just explained it to someone else what I did in cases like that. Short summary: fork processes for the really blocking stuff (disk I/O, device I/O), do the high level logic and network I/O in the parent, communicate requests/responses to the children, using e.g. socketpair (they're fast enough). So this maps the blocking I/O done in the children to socketpair I/O which you *can* select/poll/kqueue/epoll on, e.g. using libevent. Or even using OpenBSD's userland pthread, having a thread "block" on reading responses from the socketpair. >Jan Engelhardt Kind regards, Hannah.
