Re: latest CVS commit

>The only broken client I know about for sure is JAMin.  But, I expect
>it is used by more than 1% of JACK users.  Breaking it will probably
>affect at least as many people as were inconvenienced by freewheeling
>problems under Linux 2.4.

the design before this change is simply wrong. thats one of the many
reasons why JACK is still at 0.99 and has not yet reached 1.0. we are
not going to freeze the API in a broken state. if the current design
was correct, the issues with freewheeling would not have been
lingering around like a fly buzzing in the back corner of a dark
closet. 

>Existing versions of JAMin will work correctly (after recompilation)
>if jack_create_client() is undefined.  But, you made the mistake of
>changing the function prototype without changing its name.  That

it wasn't a mistake, it was a conscious choice. i want to break
existing clients that were using this function because it does not and
cannot work in the way that i think it should work. clients that use
jack_create_thread() are creating threads that cannot relinquish and
reacquire RT scheduling. this may seem minor given that they will
likely not be participating in any freewheel activity (though they may
well do so). i don't consider it minor. i think that any RT thread
within JACK must be able to do this with no issues.

>This whole change is poorly timed and something of an overreaction.

at some point recently, i was getting 1-2 bug reports every week from
people who exported with ardour and then had terrible behaviour from
JACK afterwards. providing a feature (freewheeling) that inevitably
leads to poor performance for no apparent reason is not a good idea.

>Introducing binary and source compatibility surely does more harm than
>good.  It's going to take us at least another month or two to smoke
>out all the other problems inadvertantly introduced by this fix.

what you seem to have failed to notice is that for months, JACK has
been reliant on a function that already embodies 90% of what this fix
does. jack_acquire_realtime_scheduling() has to work, or a number of
things will fail. all the cruft that was in jack_create_thread() was
there because we adopted the wrong priviledge model (parents granting
children scheduling classes etc).

>Meanwhile, there are significant JACK enhancements that will not be
>widely available because of it.

We have not done a new release of JACK for months when we could
have. Even if this takes another month, which I seriously doubt, its
really no different than the status quo that we've lived with for a
while. 

If you really want to burden the API with "jack_create_thread()" and
jack_create_thread_legacy()", i am not opposed to that, but i think
its a mistake. the broken one would need to be removed for 1.0 anyway,
which is not far off according to most perspectives, i think.

--p


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click