Patch for extended thread model proposal

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

Re: Patch for extended thread model proposal

Jonatan Liljedahl
Stéphane Letz wrote:

> 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.

But isn't pthread_getschedparam() the same on OSX and windows? Then we
could have a function to return prio and sched_param struct as this
does. Or at least a function to return the pthread id of the process
thread, which is not possible for the moment?

--
/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)
Jonatan Liljedahl wrote:

> Stéphane Letz wrote:
>> 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.
>
> But isn't pthread_getschedparam() the same on OSX and windows? Then we
> could have a function to return prio and sched_param struct as this
> does. Or at least a function to return the pthread id of the process
> thread, which is not possible for the moment?

IMHO, if it's possible then we should simply have a function that
returns an integer which can be succesfully passed as
jack_client_create_thread()'s third argument ('int priority'). Anything
beyond that would be redundant.

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

Jonatan Liljedahl
In reply to this post by Jonatan Liljedahl
Jonatan Liljedahl wrote:

> Stéphane Letz wrote:
>> 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.
>
> But isn't pthread_getschedparam() the same on OSX and windows? Then we
> could have a function to return prio and sched_param struct as this
> does. Or at least a function to return the pthread id of the process
> thread, which is not possible for the moment?

Sorry, I just found jack_client_thread_id()... :)

I just tested this in my code:

init() {
    struct sched_param proc_param;
    int proc_policy;
...
create client
set process callback
set shutdown handler
get samplerate
activate client
...
    pthread_getschedparam(jack_client_thread_id(client),
        &proc_policy, &proc_param);

    jack_client_create_thread(client, &disk_thread_id,
        proc_param.sched_priority-1, 1, disk_thread, 0);
}

And it seems to work fine, no usleep...

A question: does the realtime arg to jack_client_create_thread() take
into account if the client runs in realtime or not? Is it OK to just
pass 1 here or should I pass the return of jack_is_realtime(client)?

--
/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

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

Le 10 mars 08 à 17:13, Juuso Alasuutari a écrit :

> 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.

Maybe jack_client_create_thread API was created without asking OSX  
guys at all?? ((:

>
>
> 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... :)

Well I would consider this as a bug... if you cannot be sure the  
thread runs with the appropriate priority...this issue is somewhat not  
related to jack at all.
Any way to find out more info on that?

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)
In reply to this post by Jonatan Liljedahl
Jonatan Liljedahl wrote:

> I just tested this in my code:
>
> init() {
>     struct sched_param proc_param;
>     int proc_policy;
> ...
> create client
> set process callback
> set shutdown handler
> get samplerate
> activate client
> ...
>     pthread_getschedparam(jack_client_thread_id(client),
>         &proc_policy, &proc_param);
>
>     jack_client_create_thread(client, &disk_thread_id,
>         proc_param.sched_priority-1, 1, disk_thread, 0);
> }
>
> And it seems to work fine, no usleep...

It seems to work here, too.

I had the pthread_getschedparam call inside the process thread itself,
and there it required usleep(1); to return the right result. But if I do
it right after jack_activate(), like in your code above, it works. Odd.

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 Stéphane Letz
Stéphane Letz wrote:

>
> Le 10 mars 08 à 17:13, Juuso Alasuutari a écrit :
>> 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... :)
>
> Well I would consider this as a bug... if you cannot be sure the thread
> runs with the appropriate priority...this issue is somewhat not related
> to jack at all.
> Any way to find out more info on that?

Well, I tried it like Jonatan Liljedahl did, by doing
pthread_getschedparam() right after jack_activate() outside the process
thread, and there it works. The difference is that when I did it in the
process thread I used pthread_self() to get the pthread_t, but now I'm
using jack_client_thread_id().

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 Mon, Mar 10, 2008 at 07:14:43PM +0200, Juuso Alasuutari wrote:

> Well, I tried it like Jonatan Liljedahl did, by doing
> pthread_getschedparam() right after jack_activate() outside the process
> thread, and there it works. The difference is that when I did it in the
> process thread I used pthread_self() to get the pthread_t, but now I'm
> using jack_client_thread_id().

ISTR (from a very distant past of using pthreads on Solaris) that
the thread_id given by pthread_create() is valid only from *when
that function returns*. So if the new thread preempts its creator
it may not be valid inside that thread from the start. Which probably
also means that pthread_self() is not valid in that case. Which
explains what you see. I bet that even using jack_client_thread_id()
inside the thread will not work the first time (before the thread
has waited at least once).

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 10 mars 08 à 18:35, Fons Adriaensen a écrit :

> On Mon, Mar 10, 2008 at 07:14:43PM +0200, Juuso Alasuutari wrote:
>
>> Well, I tried it like Jonatan Liljedahl did, by doing
>> pthread_getschedparam() right after jack_activate() outside the  
>> process
>> thread, and there it works. The difference is that when I did it in  
>> the
>> process thread I used pthread_self() to get the pthread_t, but now  
>> I'm
>> using jack_client_thread_id().
>
> ISTR (from a very distant past of using pthreads on Solaris) that
> the thread_id given by pthread_create() is valid only from *when
> that function returns*. So if the new thread preempts its creator
> it may not be valid inside that thread from the start. Which probably
> also means that pthread_self() is not valid in that case. Which
> explains what you see. I bet that even using jack_client_thread_id()
> inside the thread will not work the first time (before the thread
> has waited at least once).

Hum...that seems quite annoying, if the thread context is not  
guaranteed when the start_routine begin execution.  I guess we could  
use a workaround like:

void* start_routine(void* arg)
{
        jack_client_t* client = (jack_client_t*) arg;

        // Execute one "dummy cycle
        jack_nframes_t frame = jack_cycle_wait (client);
        jack_cycle_signal (client, 0);

        // Our init code here

        // Real processing
        while(1) {
                frame = jack_cycle_wait (client);
                int status = process(....);
                jack_cycle_signal (client, status);
        }
}

But not so satistactory....

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 Tue, Mar 11, 2008 at 11:25:54AM +0100, Stéphane Letz wrote:

> Hum...that seems quite annoying, if the thread context is not guaranteed
> when the start_routine begin execution.  I guess we could use a workaround
> like:
>
> void* start_routine(void* arg)
> {
> jack_client_t* client = (jack_client_t*) arg;
>
> // Execute one "dummy cycle
> jack_nframes_t frame = jack_cycle_wait (client);
> jack_cycle_signal (client, 0);
>
> // Our init code here
>
> // Real processing
> while(1) {
> frame = jack_cycle_wait (client);
> int status = process(....);
> jack_cycle_signal (client, status);
> }
> }


It could be done in the library by putting a wrapper
around the user-supplied thread_main(). But even
executing a cycle does not 100% ensure that the
phtread_create hase returned. What is needed is
a sema sigalled after pthread_create() and waited
for by the new thread.

Note that this does not only affect getting the
thread's priority, but every operation that relies
on the thread_id being known.


--
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 11 mars 08 à 13:00, Fons Adriaensen a écrit :

> On Tue, Mar 11, 2008 at 11:25:54AM +0100, Stéphane Letz wrote:
>
>> Hum...that seems quite annoying, if the thread context is not  
>> guaranteed
>> when the start_routine begin execution.  I guess we could use a  
>> workaround
>> like:
>>
>> void* start_routine(void* arg)
>> {
>> jack_client_t* client = (jack_client_t*) arg;
>>
>> // Execute one "dummy cycle
>> jack_nframes_t frame = jack_cycle_wait (client);
>> jack_cycle_signal (client, 0);
>>
>> // Our init code here
>>
>> // Real processing
>> while(1) {
>> frame = jack_cycle_wait (client);
>> int status = process(....);
>> jack_cycle_signal (client, status);
>> }
>> }
>
>
> It could be done in the library by putting a wrapper
> around the user-supplied thread_main(). But even
> executing a cycle does not 100% ensure that the
> phtread_create hase returned.

I think it does. What jack_activate does is;

- start thread (with phtread_create)

- issue an "activate" request to the server

So jack_cycle_wait will return only when the client has actually be  
activated and signaled in the server, so *after* the phtread_create  
has returned.

> What is needed is
> a sema sigalled after pthread_create() and waited
> for by the new thread.
>
> Note that this does not only affect getting the
> thread's priority, but every operation that relies
> on the thread_id being known.
>

And yes the "dummy" cycle could be done in libjack. Seems like a  
simple solution that does not require to use another sync mechanism  
only for this purpose.

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
12