On 15.04.10 12:37, Stefan Sayer wrote:
Hi,
the threadpool is optional (compile time), so that doesn't need to be
a problem.
But I, too, wonder whethere it should be necessary to block in the
event handler; for example, if you think you need to block in
onInvite, you can most probably defer the processing to later, e.g.
call AmSession::onInvite and add to media processor later, when you
process your event from user_timer (yet its possible we got hooked all
too much on the async/event loop style of implementation).
I think an another event should be used as well, which covers the case
that the condition became 'true'. Anyway, Roberts idea might be
perfectly legal and good in his case. I was just giving out a warning
about waiting for something within an event handler ;-)
-Raphael.
Stefan
Raphael Coeffic wrote:
Hi Robert,
Thanks for the patch!
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.
Moreover, Stefan has made some plans to use a threadpool for the
session event loop, instead of having one thread per session. This
increases the performances dramatically when running signaling only
applications. The drawback is that the event loop becomes even more
sensible, as blocking in an event handler will also prevent other
sessions from being processed.
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.
With a little bit more explaination, we might be able to discuss a
more asynchronous / scalable solution to your issue.
Cheers
Raphael.
On 14.04.10 15:09, Robert Szokovacs wrote:
Hi,
I started using AmCondition and noticed it didn't wrap
pthread_cond_timedwait(). As I couldn't use UserTimer because I wait in
onInvite() so the timeout events don't get delivered, I added the
functionality to AmCondition. Patch attached.
br
Szo
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
