[Jack-Devel] R: Jack thread cancellation

PrevNext  Index
DateMon, 06 May 2013 11:31:03 +0200
From MONTANARO Luciano (MM) <[hidden] at magnetimarelli dot com>
ToStéphane Letz <[hidden] at grame dot fr>
Cc"[hidden] at lists dot jackaudio dot org" <[hidden] at lists dot jackaudio dot org>
In-Reply-ToStéphane Letz Re: [Jack-Devel] Jack thread cancellation

> -----Messaggio originale-----
> Da: Stéphane Letz [mailto:[hidden]]
> Inviato: venerdì 3 maggio 2013 17:24
> A: MONTANARO Luciano (MM)
> Cc: [hidden]
> Oggetto: Re: [Jack-Devel] Jack thread cancellation
>
>
> Le 3 mai 2013 à 17:11, "MONTANARO Luciano (MM)"
> <[hidden]> a écrit :
>
> > Hi list,
> >
> > I have an embedded application that makes use of jack (Version 1.9.8).
> > I have started seeing crashes from the clients in the JackError() call.
> >
> > The stack trace shows that the thread executing (Which is handling the
> > JackSocketChannel::Execute call) receives is being killed
> > (sigcancel_handler is called) and since the thread is in
> > CANCEL_ASYNCHRONOUS mode, it crashes since an unsafe function is
> > called (vnsprintf).
> >
> > The client I am using is actually unaware of using Jack at all, it is
> > using the alsa jack plugin, and it opens/closes the alsa devices many
> > times during its lifetime.
> >
> > Now, I have a few doubts:
> > - Why are threads created with cancellation type
> PTHREAD_CANCEL_ASYNCHRONOUS?
> >  Is this because the realtime threads need this or is there some other
> reason?
>
> Old written code…. AFAIR PTHREAD_CANCEL_DEFERRED was not working so well
> (or possibly not the same way on test OS like Linux and OSX) so
> PTHREAD_CANCEL_ASYNCHRONOUS was choses.
>

Thanks, that is one og my hypothesis. The other one was that the process callback is likely to have no cancellation point, given the restriction about doing no io.

> > - Would it be possible to mark the threads used by the
> > JackMessageBuffer and  JackSocketClientChannel as PTHREAD_CANCEL_DELAYED
> instead?
>
> You mean PTHREAD_CANCEL_DEFERRED?  Possibly yes.  Try to test it.
>


Yes, sorry for the confusion. I am going to test it, I just wanted to make sure I was not missing something important.

> > - Why is fThread.Kill() used in JackSocketClientChannel::Stop instead of
> fThread.Stop()?
>
> Same answer as before, Stop was not working reliably on all testes OSs, so
> Kill was used.
>

All right, then I can test it in my setup... I think the environment is controlled enough that using Stop should not have drawbacks.

>
> >  The latter should still work, and allow the Execute() to terminate it
> > communication  with the server.
> >
> > Thanks in advance,
> > Luciano
> > --
>
> Stéphane

Thank you again for the clarification.

Luciano

VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW WEB SITE!   www.magnetimarelli.com

Confidential Notice: This message - including its attachments - may contain proprietary, confidential and/or legally protected information and is intended solely for the use of the designated addressee(s) above. If you are not the intended recipient be aware that any downloading, copying, disclosure, distribution or use of the contents of the above information is strictly prohibited.
If you have received this communication by mistake, please forward the message back to the sender at the email address above, delete the message from all mailboxes and any other electronic storage medium and destroy all copies.
Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free. Therefore we do not assure that this message is complete or accurate and we do not accept liability for any errors or omissions in the contents of this message.
PrevNext  Index

1367832671.29903_0.ltw:2,a <67BA5DEFFBE7BF46B4C53F7E5FC5AD4423A1920632 at MXCL13 dot fgremc dot it>