Re: [gtk-list] Re: callback synchronisation

[Drazen Kacar <dave srce hr>]

Paul Barton-Davis wrote:

> [ Your message suggested that you have a good reason to be using SIGPOLL
>   rather than having the main loop including the relevant fd's in
>   its own select/poll waiting. So I'll ignore that possibility.
> ]

Yes, poll(2) doesn't do anything meaningfull with audio devices on Solaris.

> How are you installing the callback on SIGPOLL ? The current version
> of glib doesn't provide direct support for callbacks on POSIX
> signals. It sounds as if you are doing something very similar to Tim
> Janik's stuff for Beast that provides a layer about g_source_add() for
> POSIX signals. I ripped it out of Beast (well ... copied
> glib_extra.[ch] :), and it works wonderfully for me.

It is Tim's stuff. A while ago I needed it for another application, so
I asked here and Tim sent me his code. I only added a couple of casts to
shut up the compiler warnings. I never looked at the Beast, but I suppose
it's the same code.

> However, Tim's code doesn't directly receive the POSIX signal;
> instead, it appears to rely on the signal interrupting the glib main
> loop (see below for a comment on this), at which point the g_source_()
> functions get executed and the callback you set up runs. This isn't

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

> adequate for my purposes, so I doubled up - I handle the
> non-GTK-related aspects of the signal from a direct POSIX signal
> handler installed with signal(2), and the GTK-related parts with a
> callback installed with Tim's g_signal_add(). The only GTK-related
> thing that happens in the POSIX handler is a call to Tim's
> g_signal_notify(), which ensures that the GTK part will execute right
> after the POSIX signal handler has returned: the glib main loop
> returns from poll/select because of the signal, checks to see if any
> "input" is available, which is true because I called
> g_signal_notify(), and then executes the callback.

I want it to return to the current callback (if any) and call the
one installed with g_signal_notify() after that one returns. That would
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.

Unfortunately, I don't have non-GTK-related signal handlers. Both of them
should update widgets.

> One important note with this approach: if you set up POSIX signal
> handling in a way that allows reentrancy, you may well be doomed.  My
> MIDI sequencer SoftWerk gets a SIGALRM from the OS every 25ms, but it
> uses signal(2) to setup the handler, which prevents reentrancy; in
> fact, it requires that the signal handler is "rearmed" after every
> signal.  This works fine for me. That is, if my SIGALRM handler isn't
> done in 25ms (hard to imagine, but not impossible), then we simply
> won't get another SIGALRM when the next one is due.

I'm using sigaction(2), which blocks SIGPOLL while I'm in the handler.
I don't know what glib uses for SIGALRM. Does it use SIGALRM at all
for g_timeout_add(), or it's handled by select/poll timeout? In any
case, I can afford to lose timer events, but I can't afford losing SIGPOLL
(they don't always come in bursts).

> >If not, I need to set up some lock for my data, which is probably possible,
> >but I don't know what to do when I detect that another callback holds the
> >lock, ie. how do I let it continue its job and then return to the current
> >callback.
> 
> I need to do this as well sometimes, so I use <asm/atomic.h> on Linux
> and equivalents on other systems. Within critical sections, I do this:

Not available on Solaris in userland. :-(

[...]

> To be honest, you could use an int for this on most platforms, but I
> feel more comfortable with the asm-level guarantees that this provides
> for SMP systems.

Exactly. I'm not sure if "just try to run fast" would work good enough.

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