On 19 Aug 2008, at 18:31, Benny Prijono wrote: > 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. Well, that's one problem solved at least. :) > 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 ...but this problem remains. It seems to me that this is a OS X specific issue as well, as I have not encountered in on linux. So are you suggesting I just ignore this return value from pjsip_endpt_handle_events2? Ruud Klaver AG Projects
