Re: [Jack-Devel] Graph callback and client state

PrevNext  Index
DateWed, 10 Apr 2013 01:07:36 +0200
From Pawel <[hidden] at wp dot pl>
ToStéphane Letz <[hidden] at grame dot fr>, Paul Davis <[hidden] at linuxaudiosystems dot com>
Ccjack-devel <[hidden] at lists dot jackaudio dot org>
Follow-UpPaul Davis Re: [Jack-Devel] Graph callback and client state
Dnia Wtorek, 9 Kwietnia 2013 22:16 Stéphane Letz <[hidden]> napisa³(a) 
> 
> Le 9 avr. 2013 ? 21:51, Paul Davis <[hidden]> a écrit :
> 
> > 
> > 
> > On Tue, Apr 9, 2013 at 3:33 PM, Harry van Haaren <[hidden]> wrote:
> > On Tue, Apr 9, 2013 at 7:45 PM, Stéphane Letz <[hidden]> wrote:
> > > You can never be sure that ports returned by jack_get_ports are always valid
> > 
> > Any chance that adding a flag,  "JackPortIsActive" to JackPortFlags allows the functionality to be implemented?
> > On activation, the JACK server marks all of the client owned ports as "active".
> > Patchbay managers etc call jack_port_flags() and can query if its an "active" port or not?
> > 
> > there is always a race ... sometime between when you get the ports and when you use the information, ports could be added, removed or become inactive.

I disagree with this. Client call jack_get_ports and got "snapshot" of Jack Graph. Now client try process this port using different API (e.g. jack_connnect, jack_disconnect, jack_port_by_name etc.). Now you say that things can meantime change .. OFC here we agree .. but ..

- new port will be add => client didn't know about it (yet) - this nothing change for us in this moment.

- port removed => this is the real error - functions that try to use this port (port-name) should fail. And they did e.g. jack_connect return error, because port doesn't exists anymore. It's fine.

- port is inactive - ?? Client suppose that port exits - and it exists, so it's "broken" ... but because jack server KNOW this before serve it to client  - it should at least try to avoid problems.

What I want to say - we can't fix this ultimately - but jack server should at least TRY to protect client from evil - and in this case he definitely can. So , once again - jack_get_ports shouldn't return broken ports if he know they are useless for client.

I also can't find a problem in jack_is_port_active. Example:
jack_get_ports(....)
<--- obviously some time here - and things can change ..
jack_port_t* port = jack_get_port_by_name ( ...)
<-- still things can change - but if we got port == NULL we fail here and remove port from patchbay graph.
jack_port_is_active ( client, port); 
# return 0 on success i.e. port still exists and is active. Otherwise we can return some codes like "1 - not active, 2 - not exists .. etc, but for me (as patch manager maintainer) it's clear that in this short time window port is broken. I just mark it as "unusable" .. and wait for another event.

BTW. thanks for attention in this thread.

--
Regards
Pawel / Xj.

> 
> 
> This is more or less my point : "ports could be added, removed or become inactive."  Inactive state is not so specific… so why bother to treat this case only? This racy API cannot be corrected.
> 
> Stéphane
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
PrevNext  Index

1365548873.24465_0.ltw:2,a <51649f38192041.21726902 at wp dot pl>