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

PrevNext  Index
DateThu, 30 May 2013 15:31:32 +0200
From Pawel <[hidden] at wp dot pl>
Tojack-devel <[hidden] at lists dot jackaudio dot org>
> Dnia Šroda, 10 Kwietnia 2013 12:46 Peter Nelson <[hidden]> napisa³(a) 
> > On Tue, 2013-04-09 at 15:51 -0400, Paul Davis wrote:
> > > 
> > > 
> > > 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.
> > 
> > Of course its possible that the port is removed in the mean time. In
> > that case there is absolutely no problem because there is no need to
> > care about a non-existent port because you can't (dis)connect it anyway.
> > 
> > This 'problem' manifests in vastly more complex connection management
> > code, as connection managers have to additionally monitor that their
> > connection attempt worked and may have to repeatedly retry making the
> > connection later because it still may not be active yet.
> > 
> > If inactive ports are not listed then connection managers may simply
> > fire & forget the connect request. If the port no longer exists, so
> > what, it can't be connected anyway.
> > 
> > Of course making this change doesn't fix all problems, but it does help
> > one. Surely that's an advantage? 
> 
> Exactly ;-)
> 
> Harry's idea is also valid - we can know is port is active and for example mark it "gray". It's not a problem that this info would be outdated - we already accept this approach in other API calls. As was said by Paul and Stephane - even port name could be outdated on this time i.e. when we call jack_get_ports , we must humbly accept scenario where in some other thread this port is just right now removed ;-) ... but this shouldn't stop us to TRY process this port - because then it will be 
> paranoid ;-)
> 
> Xj

I'm start digging  in a Jack1 code. I think add support JackPortIsActive flag can be rather complex - because then we need to handle it in few calls (e.g. jack_port_register, jack_activate, jack_deactivate ...).

.. but add jack_port_is_active seems to be pretty simple. In my conception jack_port_is_active will be some kind of trick, cause it will return state of entire client, and we will not keep individual port states i.e. there will be not possible for client to have active and inactive ports in same time.

jack_port_t structure already contain client_id field, so  maybe we can somehow get "active" filed from jack_client_control_t from libjack perspective i.e. without call to jackd ?

Here is my question to jack gurus - is this allowed to obtain such info directly from libjack ? Or maybe there is better solution to get "active" state info ?

--
Pawel
PrevNext  Index

1369920707.20802_0.ltw:2,a <51a754b4d71c50.14561440 at wp dot pl>