On Tue, Aug 19, 2008 at 11:07 AM, Ruud Klaver <ruud at ag-projects.com> wrote: > > You were right about the select() failing. I have traced the sequence > of events to the following: > > 1. select() returns -1 and errno is set to EBADF (Bad file descriptor). > 2. pj_ioqueue_poll returns this errno value in pj style and negative > (-120009) > 3. in pjsip_endpt_handle_events2 errno is queried again (through > pj_get_netos_error()) and somehow has been changed to ETIMEDOUT in the > meantime. > > This happens because when select() returns -1, the pjsip_endpt_handle_events2() will call sleep(), so that error in select() will not cause CPU to spin indefinitely. Unfortunately, calling sleep() in MacOS X always reset errno to ETIMEDOUT, and we don't save the original errno returned by select(), so that's why the returned status now changed to ETIMEDOUT. I've just fixed this in the latest SVN (so now the correct status will be returned). Thanks for the info. > What I am doing is having pj_ioqueue_unregister() called from a > different thread than the select() is active in. This seems to confuse > the select(). > > How is this supposed to work, since ioqueue->lock is released around > the select() statement? > > Yes, the lock is released before select() so that multiple threads can poll at the same time. I'm not sure what's the best way to handle this. Frankly I think this is just something that we'd have to accept as normal situation, just like when two threads are woken up by select(), and only one will successfully call recv() and the other will get EWOULDBLOCK error. Cheers Benny > Ruud Klaver > AG Projects > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080819/c85e0340/attachment.html
