[vlc-devel] compat pthread_cancel

[Jean-Philippe André]

Hi,

2011/6/3 Rémi Denis-Courmont <remi at remlab.net>

> Le jeudi 2 juin 2011 19:03:03 Jean-Baptiste Kempf, vous avez écrit :
> > On Thu, Jun 02, 2011 at 06:58:57PM +0300, Rémi Denis-Courmont wrote :
> > > Le jeudi 2 juin 2011 18:47:48 Jean-Baptiste Kempf, vous avez écrit :
> > > > Taken from the vlc-android tree, and rebased/merged/fixed, here is
> the
> > > > pthread_cancel for compat.
>


> > > And then, either this whole thing makes no sense or it relies on
> > > super-POSIX properties of Android libc that I don't know and thus
> cannot
> > > review.
>

The only super-posix property I remember is that poll() returns whenever the
process receives a signal. (ppoll does not exist)


>  > Arf... What parts seem dubious?
>
> In my world:
> * Signal handlers are (unfortunately) per-process, not per-thread.
>

Yes, unfortunately. This can indeed lead to issues.


> * Setting thread keys to zero is pointless.
>

Indeed, but not an issue.


> * POSIX thread functions are not async-signal-safe, meaning they are not
> defined within signal handlers.
>

Thus many FIXME and 'Why?' comments^^
Unfortunately I didn't find any other easily implementable solution that
wouldn't be based on signals and that doesn't add yet another main thread
watching the others.
Maybe futexes are the way to go, but my knowledge of them is even worse than
that of pthread^^


> * pthread_setcancelstate() is not a cancellation point.
>

OK, my bad. Slight misunderstanding/misreading of the API back then. Easy to
remove the cancellation point here :)

 I also don't understand where cancellation cleanup handlers
> (vlc_cleanup_push
> and friends) are dealt with.


They are dealt with by the call to pthread_exit. If there's any vlc-specific
task to execute, then yes, it's not being taken care of.

The code works, according to experimental testing, but it is not meant to be
correct. That's one reason why I've never submitted it.
Btw, cancellation on Android is probably one of the worst ideas we could
ever have ;-)

Best,


-- 
Jean-Philippe André
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20110611/a0ecb066/attachment.html>