[linux-audio-dev] meterbridge 0.0.4

[Joern Nettingsmeier]

Steve Harris wrote:
> 
> On Thu, Oct 03, 2002 at 12:38:33 +0200, Joern Nettingsmeier wrote:
> > > That is just becuase it tried to connect as brdige, and if it cant tries
> > > bridge-<pid>
> >
> > ok, i could have thought of that myself....
> 
> Not that this is a good thing, it should be fixed. I didn´t check to see
> if there was a client name query function. If so I will use that, if not I
> will probably just move to always using bridge-<pid>. ¿comments?

hehe, watch out and stay out of the sun, your punctuation is already
becoming spanish :)
i like the pid approach. i don't know if i fully understand its
implications, but it feels like this should be added to the jack docs as
a "best practise" recommendation.

> > > Yeah, thats not fixable. Making them not crash is probably better.
> > > I'd like to get to the bottom of your segfual problem. I though id
> > > probably fixed it.
> >
> > just to clarify, i mean killall -TERM, not killall -KILL. out of
> > curiousity, is there a way to tell the scheduler not to pre-empt the
> > process until the port cleanup is completed ? (sorry if this is a dumb
> > question, i don't know much about unix programming...)
> 
> Sig term (should) cause the cleanup handler to be called, nothing will
> happen to the process other than that IIRC. ITs up to you what you do with
> the signal, but its polite to exit afterwards ;)

;)

i was thinking of a situation like this:

some meterbridges run.
i issue "killall meterbridge".
meterbridge receives a SIGTERM, the exit handler is called and all
functions you registered with atexit() are executed (i.e. the port
restoration).
the problem is, when there are multiple processes called meterbridge,
they will all be killed at once and their exit functions will likely run
concurrently. which is bad, because one instance might just have
disconnected, gets pre-empted without having restored the old
connection, another instance tries to clean up and BANG! the signal
chain is broken. i *think* this is what i'm seeing.
how would you (in theory) handle this ? is there a way for userspace
apps to declare a part of their code atomic ? if not, would it make
sense to use a lockfile upon entering the port reconnection code ?
(not that i'm interested in this feature... it's just that i want to
know how userspace is supposed to handle situations like this.)




-- 
Jörn Nettingsmeier     
Kurfürstenstr 49, 45138 Essen, Germany      
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)