Patch for extended thread model proposal

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Patch for extended thread model proposal

Stéphane Letz
Hi All,

Here is a patch for the thread model proposal that was discussed at  
LAC "Future of JACK" meeting. So basically the idea is to give clients  
an alternate way to setup the audio RT code.

1) New "thread callback" type, that is the complete function to be  
called by RT thread:

        typedef void *(*JackThreadCallback)(void* arg);

2) New function to setup the "thread callback"  to be called by RT  
thread:

  int jack_set_process_thread(jack_client_t* client,  
JackThreadCallback fun, void *arg);
       
3) And a couple of functions to interact with libjack:

        // Wait on the input "semaphore"
        jack_nframes_t jack_cycle_wait (jack_client_t* client);

        // Signal next clients in the graph
        void jack_cycle_signal (jack_client_t* client, int status);


A client will typically do :

        int process (jack_nframes_t nframes)
        {
                // Audio process
                return 0;
        }

        static void* jack_thread(void *arg)
        {
                jack_client_t* client = (jack_client_t*) arg;

                // possibly INIT code
       
                while (1) {
                        jack_nframes_t frames = jack_cycle_wait (client);
                        int status = _process(frames);
                        jack_cycle_signal (client, status);
                        // possibly additional code
                }
       
                return 0;
        }

And :

        ....
        jack_set_process_thread(client, jack_thread, client);
        ....


Jack ports buffers are "valid" between the calls of jack_cycle_wait  
and jack_cycle_signal, but the RT callback can possibly do more things  
*after* having called  jack_cycle_signal that continue graph  
execution. Having access to jack_cycle_wait/jack_cycle_signal gives a  
more flexible control for an application to interact with libjack,  
like getting several buffers and starting a processing, or  
initializing a context that needs to be keep in the thread scope.

Current "jack_set_process_callback" and new "jack_set_process_thread"  
are exclusive, and libjack check for that. There is no "complete"  
contradiction to use "jack_cycle_wait/jack_cycle_signal" functions in  
a  process callback (setup with jack_set_process_callback) although  
this is considered a corner case.

The new jack_cycle_wait/jack_cycle_signal somewhat replaces the "Fons  
special" jack_thread_wait API, so that jack_thread_wait ==  
jack_cycle_signal(); jack_cycle_wait ();  (note the reverse order, the  
"jack_thread_wait" was first signaling the next client, then waiting  
for next cycle...) Obviously it would be better to remove the old API  
(or mark it obsolete) and keep the new one only, if this does not  
break too much clients.

The tw1.c example show the use of the new API.

Testing and comments welcomed!

Stéphane


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

tw1.c (5K) Download Attachment
thread_model.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Fons Adriaensen-2
On Wed, Mar 05, 2008 at 12:28:04PM +0100, Stéphane Letz wrote:

> Here is a patch for the thread model proposal that was discussed at LAC
> "Future of JACK" meeting. So basically the idea is to give clients an
> alternate way to setup the audio RT code.

Sorry for the delay, my internet access at home was
interrupted from last tuesday up until a few moments
ago.

> ...
> ...
> Testing and comments welcomed!

Seems perfectly OK to me. Testing will follow - there's
only 36 hours in a day...


One final comment: it may look for some as if jack(d) is
moving away from its prime quality: forced synchronous
execution of audio processing code. This is *not* the
case. The only essential difference between the two
models is the location of a while() loop.

For the 'thread mode' it's in the user's code, as shown
in Stephane's example.

For the 'callback mode', it's is inside the library,
e.g. something like:

nframes = engine->nframes;
while (1)
{
   status = process_callback (nframes, arg);
   jack_cycle_signal (client, status);
   nframes = jack_cycle_wait (client);
}

And that's the only real difference between the two
modes. If you look at the code above, it's also clear
that even the process_callback could just call the two
new functions itself instead of returning and having
the loop do it.

--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

juuso.alasuutari (Bugzilla)
In reply to this post by Stéphane Letz
Stéphane Letz wrote:
> Hi All,
>
> Here is a patch for the thread model proposal that was discussed at LAC
> "Future of JACK" meeting. So basically the idea is to give clients an
> alternate way to setup the audio RT code.

I changed my Snarl project to use the new model, and it works without a
hitch. There's still one thing that I was left wondering, though. If I
want to fire up worker threads before entering the wait/signal loop, how
do I find out what priority to set for them?

The problem is that the process thread doesn't seem to acquire real-time
priority before the first jack_cycle_wait(), and so I can't create the
worker threads with the same priority.

Here's an example:

void
print_priority (pthread_t tid)
{
        int policy;
        struct sched_param param;
        pthread_getschedparam (tid, &policy, &param);
        printf ("%s %i\n",
                (policy == SCHED_FIFO) ? "SCHED_FIFO"
                : (policy == SCHED_RR) ? "SCHED_RR"
                : (policy == SCHED_OTHER) ? "SCHED_OTHER" : "unknown",
                param.sched_priority);
}

void *
process_thread (void *arg)
{
        jack_client_t *client = (jack_client_t *) arg;
        jack_nframes_t nframes;

        /* This will print "SCHED_OTHER 0" */
        print_priority (pthread_self());

        while (1)
        {
                nframes = jack_cycle_wait (client);

                /* This will print "SCHED_RR 9" */
                print_priority (pthread_self());

                do_stuff();
                jack_cycle_signal (client, 0);
        }
}


You can see that if I would call jack_client_create_thread() before the
while loop, I wouldn't know what to pass as the priority argument. And I
think creating the worker threads inside the wait/signal loop is out of
the question.

Juuso

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

juuso.alasuutari (Bugzilla)
Juuso Alasuutari wrote:
> I changed my Snarl project to use the new model, and it works without a
> hitch. There's still one thing that I was left wondering, though. If I
> want to fire up worker threads before entering the wait/signal loop, how
> do I find out what priority to set for them?
>
> The problem is that the process thread doesn't seem to acquire real-time
> priority before the first jack_cycle_wait(), and so I can't create the
> worker threads with the same priority.

Today seems a bad day for remembering stuff. I forgot to mention that
I've only tested this with jackdmp so far.

Juuso

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Stéphane Letz
In reply to this post by Fons Adriaensen-2

Le 8 mars 08 à 18:53, Fons Adriaensen a écrit :

> On Wed, Mar 05, 2008 at 12:28:04PM +0100, Stéphane Letz wrote:
>
>> Here is a patch for the thread model proposal that was discussed  
>> at LAC
>> "Future of JACK" meeting. So basically the idea is to give clients an
>> alternate way to setup the audio RT code.
>
> Sorry for the delay, my internet access at home was
> interrupted from last tuesday up until a few moments
> ago.
>
>> ...
>> ...
>> Testing and comments welcomed!
>
> Seems perfectly OK to me. Testing will follow - there's
> only 36 hours in a day...
>
>
> One final comment: it may look for some as if jack(d) is
> moving away from its prime quality: forced synchronous
> execution of audio processing code. This is *not* the
> case. The only essential difference between the two
> models is the location of a while() loop.
>
> For the 'thread mode' it's in the user's code, as shown
> in Stephane's example.
>
> For the 'callback mode', it's is inside the library,
> e.g. something like:
>
> nframes = engine->nframes;
> while (1)
> {
>    status = process_callback (nframes, arg);
>    jack_cycle_signal (client, status);
>    nframes = jack_cycle_wait (client);
> }

Only that the loop is actually more:

while (1) {
        nframes = jack_cycle_wait (client);
        status = process_callback (nframes, arg);
        jack_cycle_signal (client, status);
}

The loop starts with a jack_cycle_wait and first process_callback is  
called after the previous client have signaled this one, so the  
client can run using valid buffers.

What libjack does in "jack_activate" is creating the thread  
initiality blocked on jack_cycle_wait, until the client is really  
inserted in the graph in the server and actual processing starts.

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Stéphane Letz
In reply to this post by juuso.alasuutari (Bugzilla)

Le 8 mars 08 à 20:19, Juuso Alasuutari a écrit :

> Juuso Alasuutari wrote:
>> I changed my Snarl project to use the new model, and it works  
>> without a
>> hitch. There's still one thing that I was left wondering, though.  
>> If I
>> want to fire up worker threads before entering the wait/signal  
>> loop, how
>> do I find out what priority to set for them?
>>
>> The problem is that the process thread doesn't seem to acquire  
>> real-time
>> priority before the first jack_cycle_wait(),

It does, but....

>> and so I can't create the
>> worker threads with the same priority.
>
> Today seems a bad day for remembering stuff. I forgot to mention that
> I've only tested this with jackdmp so far.

Jackdmp actually SCHED_RR and not SCHED_FIFO ! The thing is that for  
the kind of processing that a jack like system does, I was thinking  
SCHED_RR  would be quite equivalent to SCHED_FIFO  (since the  
"maximum time quantum" a SCHED_RR thread is supposed to use on the  
maximum is higher that the jack period duration) and since a SCHED_RR  
can still be interrupted, it would possibly allow the system to  
recover more easily in case of a RT thread hanging.

Maybe this way of reasoning is wrong?

In any case you can try the SCHED_FIFO mode by correcting two lines  
in JackPosixThread.cpp file.

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Fons Adriaensen-2
In reply to this post by Stéphane Letz
On Sat, Mar 08, 2008 at 09:38:17PM +0100, Stéphane Letz wrote:

> Only that the loop is actually more:
>
> while (1) {
> nframes = jack_cycle_wait (client);
> status = process_callback (nframes, arg);
> jack_cycle_signal (client, status);
> }

which makes it even more the 'mirror image' of
the one at the client's side...

The point raised before about finding out the
process thread priority is absolutely valid.
I'd need it as well in e.g. zita_convolver.

Maybe we need:

int jack_get_process_scheduling ()
int jack_get_process_priority ()

Ciao,

--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Stéphane Letz

Le 8 mars 08 à 22:05, Fons Adriaensen a écrit :

> On Sat, Mar 08, 2008 at 09:38:17PM +0100, Stéphane Letz wrote:
>
>> Only that the loop is actually more:
>>
>> while (1) {
>> nframes = jack_cycle_wait (client);
>> status = process_callback (nframes, arg);
>> jack_cycle_signal (client, status);
>> }
>
> which makes it even more the 'mirror image' of
> the one at the client's side...
>
> The point raised before about finding out the
> process thread priority is absolutely valid.

Hum yes... but since the RT thread has the correct priority and  
scheduling when it first start, pthread API should do the job no?


> I'd need it as well in e.g. zita_convolver.
>
> Maybe we need:
>
> int jack_get_process_scheduling ()
> int jack_get_process_priority ()
>
> Ciao,
>

I don't think this is necessary, (maybe Juuso can test again and report)

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Fons Adriaensen-2
On Sat, Mar 08, 2008 at 10:30:38PM +0100, Stéphane Letz wrote:

> > The point raised before about finding out the
> > process thread priority is absolutely valid.
>
> Hum yes... but since the RT thread has the correct priority and  
> scheduling when it first start, pthread API should do the job no?

If that's the case (and it only seems natural) the
pthreads API will do the job.

Ciao,

--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

juuso.alasuutari (Bugzilla)
In reply to this post by Stéphane Letz
Stéphane Letz wrote:

> Le 8 mars 08 à 22:05, Fons Adriaensen a écrit :
>> The point raised before about finding out the
>> process thread priority is absolutely valid.
>
> Hum yes... but since the RT thread has the correct priority and  
> scheduling when it first start, pthread API should do the job no?
>
>
>> I'd need it as well in e.g. zita_convolver.
>>
>> Maybe we need:
>>
>> int jack_get_process_scheduling ()
>> int jack_get_process_priority ()
>>
>> Ciao,
>>
>
> I don't think this is necessary, (maybe Juuso can test again and report)

I did run tests yesterday already, and also today before I sent the
mail. What happens is that the pthread API always reports SCHED_OTHER
with 0 priority before the first jack_cycle_wait(). And I mean that this
happens _within_ the process thread. Look more closely at the example
code I wrote, it's all there.

The question whether SCHED_FIFO or SCHED_RR is more appropriate for
jackd[mp] isn't related to this issue.

Juuso


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

juuso.alasuutari (Bugzilla)
In reply to this post by Fons Adriaensen-2
Fons Adriaensen wrote:
> On Sat, Mar 08, 2008 at 10:30:38PM +0100, Stéphane Letz wrote:
>
>>> The point raised before about finding out the
>>> process thread priority is absolutely valid.
>> Hum yes... but since the RT thread has the correct priority and  
>> scheduling when it first start, pthread API should do the job no?
>
> If that's the case (and it only seems natural) the
> pthreads API will do the job.

The problem is that this isn't what's happening, which I find odd.

BTW: Larsl mentioned an idea of his on #lad about adding a simple
function for creating a real-time thread. Something like
jack_create_real_time_thread() which would automatically create a thread
with the same priority attributes that the process thread has.

Juuso


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Fons Adriaensen-2
On Sun, Mar 09, 2008 at 12:41:27AM +0200, Juuso Alasuutari wrote:

> Fons Adriaensen wrote:

> > If that's the case (and it only seems natural) the
> > pthreads API will do the job.
>
> The problem is that this isn't what's happening, which I find odd.
>
> BTW: Larsl mentioned an idea of his on #lad about adding a simple
> function for creating a real-time thread. Something like
> jack_create_real_time_thread() which would automatically create a thread
> with the same priority attributes that the process thread has.

I'd prefer jack_get_process_priority() in that case.
In all my apps threads are created as part of a C++
class which is a (very thin) wrapper around pthreads.
Being given an existing thread doesn't fit in with
that.

Could you try a small delay (~50ms) before reading
the priority and scheduling class ?

Ciao,

--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Stéphane Letz
In reply to this post by juuso.alasuutari (Bugzilla)

Le 8 mars 08 à 23:41, Juuso Alasuutari a écrit :

> Fons Adriaensen wrote:
>> On Sat, Mar 08, 2008 at 10:30:38PM +0100, Stéphane Letz wrote:
>>
>>>> The point raised before about finding out the
>>>> process thread priority is absolutely valid.
>>> Hum yes... but since the RT thread has the correct priority and
>>> scheduling when it first start, pthread API should do the job no?
>>
>> If that's the case (and it only seems natural) the
>> pthreads API will do the job.
>
> The problem is that this isn't what's happening, which I find odd.

OK my mistake, I read SCHED_RR in your mail where SCHED_OTHER was  
actually written...
>
> BTW: Larsl mentioned an idea of his on #lad about adding a simple
> function for creating a real-time thread. Something like
> jack_create_real_time_thread() which would automatically create a  
> thread
> with the same priority attributes that the process thread has.
>
> Juuso
>

Actually this question of thread priority management is a bit more  
complex:

- we may want to use a different prioriy for worker thread, like  
something just bellow the audio RT thread

- although OSX implement pthread API, the underlying model is still  
Mach thread:

http://developer.apple.com/documentation/Darwin/Conceptual/ 
KernelProgramming/scheduler/chapter_8_section_4.html
http://developer.apple.com/documentation/Darwin/Conceptual/ 
KernelProgramming/Mach/chapter_6_section_3.html

The audio RT is actually a "Time-constraints" thread in OSX model, in  
this case priority does not fit so well in the model: worked thread  
could possibly be also "Time-constraints thread or only "fixed-
priority" ones, what Apple actually recommend

And we probably have the same kind of issues on Windows.

Stephane



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Stéphane Letz
In reply to this post by Stéphane Letz

Le 9 mars 08 à 09:22, Fons Adriaensen a écrit :

> On Sat, Mar 08, 2008 at 10:30:38PM +0100, Stéphane Letz wrote:
>
>> I don't think this is necessary, (maybe Juuso can test again and  
>> report)
>
> I inserted his code into jdelay, and it works as expected.
>
> This is the output:
>
> jack_client_new: deprecated
> ----
> SCHED_RR 89
> ----
> SCHED_RR 89
> SCHED_RR 89
> SCHED_RR 89
> SCHED_RR 89
>
> etc.

Ok fine, this seems better, so Juuso may have a specific issue on his  
system?

>
> This is on a rather dated 2.6.13-15 system.
> Does jackmp install cleanly (replacing jack) with
> PREFIX=/usr ? If so I can test it on a more recent
> system as well.

Should yes.

>
> I attach jdelay - it also contains the code doing
> the random selection between the callback/wait
> modes which you can enable by a few comments and
> uncomments.
>
> There is still one (old) issue that prevents me
> installing jackdmp permanently: it breaks
> Linuxsampler (0.3.3) which first reports an
> 'unknow exception' and then goes into a an
> infinite loop of 'event queue full' messages.

With latest SVN?

Seems strange  as some LS guys use jackdmp without reporting any  
problem.  Can you possibly start jackdmp in verbose mode and report  
logs files on server and LinuxSampler side:

jackdmp -R -v ....

Thanks

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Stéphane Letz
In reply to this post by Stéphane Letz

Le 9 mars 08 à 14:17, Fons Adriaensen a écrit :

> On Sun, Mar 09, 2008 at 12:14:54PM +0100, Stéphane Letz wrote:
>
>> Seems also that you're using a quite old version of LS. Current  
>> version is
>> 0.5.1:
>
> I upgraded, and after some iterations this solved the
> problem: first the new LS failed because it could not
> create the disk thread. So I increased the memlock
> limit, with the result that the original error returned.
> Increasing the memlock limit again made it go away.
>
> So now it looks this was a memory problem from the
> start. It seems jackmp needs a bit more memory than
> jack (and LS 0.5.1 needs more than 0.3.3).
>
> Are you setting the thread stack sizes explicitly ?

Yes. I took the code from jackd for that.

> If not, the default size on Linux is horribly large,
> and all of it will be memlocked. This may well be
> different on OSX.
>
> Ciao,
>

The memory is not locked in jackdmp up to now. There is code  
available for that, but still not activated. On OSX mlock/munlock to  
deal with memory area are available but not mlockall/munlockall.

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Jonatan Liljedahl
In reply to this post by juuso.alasuutari (Bugzilla)
Juuso Alasuutari wrote:

> Fons Adriaensen wrote:
>> On Sat, Mar 08, 2008 at 10:30:38PM +0100, Stéphane Letz wrote:
>>
>>>> The point raised before about finding out the
>>>> process thread priority is absolutely valid.
>>> Hum yes... but since the RT thread has the correct priority and  
>>> scheduling when it first start, pthread API should do the job no?
>> If that's the case (and it only seems natural) the
>> pthreads API will do the job.
>
> The problem is that this isn't what's happening, which I find odd.
>
> BTW: Larsl mentioned an idea of his on #lad about adding a simple
> function for creating a real-time thread. Something like
> jack_create_real_time_thread() which would automatically create a thread
> with the same priority attributes that the process thread has.

there already is jack_create_client_thread(), if passed 0 for prio and 1
for realtime it could use the same prio as the process thread, or one
below...

btw, what is the advantages of using jack_create_client_thread() instead
of pthread_create_thread()?

--
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

juuso.alasuutari (Bugzilla)
In reply to this post by Stéphane Letz
Stéphane Letz wrote:

> Le 9 mars 08 à 09:22, Fons Adriaensen a écrit :
>> I inserted his code into jdelay, and it works as expected.
>>
>> This is the output:
>>
>> jack_client_new: deprecated
>> ----
>> SCHED_RR 89
>> ----
>> SCHED_RR 89
>> SCHED_RR 89
>> SCHED_RR 89
>> SCHED_RR 89
>>
>> etc.
>
> Ok fine, this seems better, so Juuso may have a specific issue on his  
> system?

You're right, it's a quirk.

Fons suggested that adding a small delay could help, and indeed doing
usleep(1); before the pthread_getschedparam call will do the trick. One
microsecond shouldn't (?) make any difference in practical terms, so I
suppose there's something going on with the OS scheduler that causes
this. (Inserting a printf call before pthread_getschedparam didn't help,
btw.)

In any case we do need a function for returning the process thread
priority for other reasons as well. Suppose a program needs to fire up
threads before registering the process thread, etc...

Juuso

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

juuso.alasuutari (Bugzilla)
In reply to this post by Jonatan Liljedahl
Jonatan Liljedahl wrote:
> Juuso Alasuutari wrote:
>> BTW: Larsl mentioned an idea of his on #lad about adding a simple
>> function for creating a real-time thread. Something like
>> jack_create_real_time_thread() which would automatically create a thread
>> with the same priority attributes that the process thread has.
>
> there already is jack_create_client_thread(), if passed 0 for prio and 1
> for realtime it could use the same prio as the process thread, or one
> below...

After reading Fons's and Stéphane's replies I think it's better to just
add a function for returning the process thread priotity, and let
clients do what they want with it.

> btw, what is the advantages of using jack_create_client_thread() instead
> of pthread_create_thread()?

I guess the jack_thread_* functions are supposed to be portable, i.e.
wrap around whatever the native API might be. They are also simplified
in comparison to pthread stuff, which is convenient for the purpose.

Juuso

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

Stéphane Letz

Le 10 mars 08 à 16:58, Juuso Alasuutari a écrit :

> Jonatan Liljedahl wrote:
>> Juuso Alasuutari wrote:
>>> BTW: Larsl mentioned an idea of his on #lad about adding a simple
>>> function for creating a real-time thread. Something like
>>> jack_create_real_time_thread() which would automatically create a  
>>> thread
>>> with the same priority attributes that the process thread has.
>>
>> there already is jack_create_client_thread(), if passed 0 for prio  
>> and 1
>> for realtime it could use the same prio as the process thread, or one
>> below...
>
> After reading Fons's and Stéphane's replies I think it's better to  
> just
> add a function for returning the process thread priotity, and let
> clients do what they want with it.

But as explained in a previous mail, I don't think we can easily  
return the "process thread priority" because it does not make much  
sense on OSX or Windows systems. I think getting info on the thread  
and doing anything appropriate is OS specific and there is not much  
sense in trying to re-invent a jack special API to access these  
informations.

Stephane



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patch for extended thread model proposal

juuso.alasuutari (Bugzilla)
Stéphane Letz wrote:

>
> Le 10 mars 08 à 16:58, Juuso Alasuutari a écrit :
>
>> Jonatan Liljedahl wrote:
>>> there already is jack_create_client_thread(), if passed 0 for prio and 1
>>> for realtime it could use the same prio as the process thread, or one
>>> below...
>>
>> After reading Fons's and Stéphane's replies I think it's better to just
>> add a function for returning the process thread priotity, and let
>> clients do what they want with it.
>
> But as explained in a previous mail, I don't think we can easily return
> the "process thread priority" because it does not make much sense on OSX
> or Windows systems. I think getting info on the thread and doing
> anything appropriate is OS specific and there is not much sense in
> trying to re-invent a jack special API to access these informations.

Okay, I probably failed to understand what you said earlier. But how
come there is an integer argument for the priority in
jack_client_create_thread() if such a thing doesn't make sense on other
than Linux/BSD systems? I would imagine that if the JACK API can allow
that argument during thread creation, it could also return a thread's
priority.

But if you think it's not a good idea I'm fine with that. I still do
think that having to usleep(1); in the process thread just to make sure
that I get the right priority is a darned hack, and I'm not sure how
comfortable I am with it. But hey, if it Works... :)

Juuso

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
12