Re: [gtk-list] Re: callback synchronisation

[Drazen Kacar <dave srce hr>]

Paul Barton-Davis wrote:

> >Meaning it interrupts any other callback which might have been running?

[snip]

> either way, your callbacks are executed serially.

Then I think I'll be fine. Is there a documentation somewhere which
guarantees this?

> >solve my problem. I'll get a burst of SIGPOLLs for one logical event, so
> >they might easily interrupt each other's callback. Actually, I think some
> >bugs might be explained that way, but I'm not sure right now.
> 
> I dont think so, as shown above. If all you do is to call
> g_signal_notify() from the handler, you will nothing to alter the
> order or relative call stack layout of the callbacks' execution.

Then I have a nasty bug somewhere else. It makes X server allocate some
50 megs and grabs it in addition to that. :-)

> HOWEVER: on some systems (Linux in particular) many system calls do
> not restart after a signal, at least not by default. You can use
> sigaction(2) to alter this (on Linux, and probably Solaris too). If

Hmm... Linux man page for sigaction(2) says:

              SA_RESTART
                    Provide behaviour compatible with BSD signal
                    semantics by  making  certain  system  calls
                    restartable across signals.

Which is not particularly helpful. Solaris man page is much better, but
read and write like calls will be restarted only on slow devices, like
terminals. Doesn't work for file system, I'm afaraid.

> call. The call returns early, apparently having failed in some way,
> when it was really just interrupted (you can discover this by checking
> errno). I don't know if this is a problem in your case.

No problem. We all use wrappers. And we all read _Worse is Better_ from
time to time. :-)

-- 
 .-.   .-.    I don't work for my employer.
(_  \ /  _)
     |        dave@srce.hr
     |        dave@fly.srk.fer.hr