Re: [linux-audio-dev] deblocking snd_seq_event_input()

On Sun, 2005-05-08 at 12:50 +0200, Fons Adriaensen wrote:
> On Sun, May 08, 2005 at 12:00:26PM +0200, Jens M Andreasen wrote:
>
> > Can't you use:
> >
> > void pthread_cleanup_push(void (*routine) (void *), void *arg);
> > void pthread_cleanup_pop(int execute);
>
> Does the thread still exist as a thread when routine() is called, or more
> specific, is routine() called from the thread's own context ? This is not clear
> from the man page - routine() could be called from a different thread than
> the one that is being cancelled.
>

After an update to Mdk-10.1 to Mdk-10.2 (Edition 2005?) I realize that:
The man pages on pthtreads is about an implementation approximately 3
generations old. Not even documented defaults are consistent with the
current implementation anymore.

Say:

   pthread_attr_init(&some_thread_attr);

.. and after reading this in man:

   inheritsched:
   ... ...
   Default value: PTHREAD_EXPLICIT_SCHED.
   ^^^^^^^^^^^^

.. one would easily be led to believe that threads by default starts as
the humbliest of creatures, unless you decide otherwise (and have the
power to do so.)

In order to actually inhibit PTHREAD_INHERIT_SCHED (which appears to be
the default of the day) you'll have to also do an explicit:

  
   pthread_attr_setinheritsched
           (&some_thread_attr,PTHREAD_EXPLICIT_SCHED);
    

.. or else your UI-thread, file-thread etc, will compete with your
RT-audio thread as peers (given you started them from some intial high
priority thread.)

Just thought I would mention it.

> But this is besides the point ...
> ...

OK! :)

-- 
   (
    )
  c[]  //  Jens M Andreasen