Mike Emmel wrote:
On 11/29/05, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
Quoting Attilio Fiandrotti:
Basically, as mike suggested, allowing an an asynchronus signal handler
to manipulate mutexes is bad, so i've turned the signal handling routine
into a thread that sinchronously waits for signals to come.
There's already a thread that only waits for signals to be signalled
via the pthrea condition. So you could remove the mutex and condition
completely and only do the sigwait() in the existing thread :)
Right thats the thread that is reading the signal number your right oops :)
I suppose denis is meaning that the sigwait() function should be moved
inside the
vt_thread() thread to encapsulate the "switch (dfb_vt->vt_sig) { ... }"
cycle and the signal handler function should be just removed, is this
correct?
Also, the dfb_vt->wait conditional variable and the dfb_vt->lock mutex
lock should be no longer necessary, right?
Should the vt_init_switching() function should still have SIGUSRn
signals masked because those will be handled by the vt_thread() thread?
If i've correctly understood, i'll rewrite the patch; as soon as i'll be
able to run dfb apps again i'll test it too.
ciao
Attilio
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev