On Thursday 15 April 2010, Raphael Coeffic wrote: Hi,
> As you pointed out, waiting in an event handler does block the event > queue, which seems obvious. This also means that waiting in an event > handler is not really the way it should be implemented, except for very > few things. Since SEMS is quite event-driven, almost everything in an application is an event handler :) > > So the crucial question is: how long do you wait there? If it is more > than a few 10s of milliseconds, you might run into troubles once we have > introduced the session threadpool. I'll make sure I have threadpools turned off > With a little bit more explaination, we might be able to discuss a more > asynchronous / scalable solution to your issue. Actually, I'm quite happy with the current (non-threadpool) one-threar-per- session setup, exactly because I can wait for async stuff in the session thread and don't have to worry about the other sessions, yet don't have to increase the complexity with elaborate statemachine in process(). In this case I have to talk to an RTP proxy before the media set-up. It means if I do it without blocking in onInvite, I would have to move most of the real work on onInvite to the process(), which wouldn't be too elegant and I really don't see why what would be the gain. br Szo _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
