On Thu, Oct 03, 2002 at 09:38:42 +0200, Joern Nettingsmeier wrote: > > 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 :)
heh, having found it on this wierd keyboard it seemed a pity to waste it;) The food and wine is more of an issue, I�m starting to fantasise about vegetables (and not having a permenant hangover). > 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. The downside is its ugly, and you tend to end up with foo-4535364 and foo-4535384 which are hard to tell apart at a glance. It does cheaply guarantee uniqueness though. > 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. Yes, thats right, the client diconnects its inputs then connects them to its outputs. That isn�t an atomic operation, so you will get connection loss in big chains. Reversig the order would help, but its not possible ATM because there is no connection quering API. I try to disconect everything and reconnect that ones that are disconnected. Maybe a jack-killall could do a better job, by telling the clients to shutdown one by one, then killing them if they dont. Does jack know the clients pid? > 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 ? Lockfiles are a pain, I try to aviod them if possible. But, yes, if I thought it was vital I would use a lockfile. - Steve
