Hi,<br><br><div class="gmail_quote">2011/6/3 Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net">remi@remlab.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Le jeudi 2 juin 2011 19:03:03 Jean-Baptiste Kempf, vous avez écrit :<br>
<div class="im">> On Thu, Jun 02, 2011 at 06:58:57PM +0300, Rémi Denis-Courmont wrote :<br>
> > Le jeudi 2 juin 2011 18:47:48 Jean-Baptiste Kempf, vous avez écrit :<br>
> > > Taken from the vlc-android tree, and rebased/merged/fixed, here is the<br>
> > > pthread_cancel for compat.</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> > And then, either this whole thing makes no sense or it relies on<br>
> > super-POSIX properties of Android libc that I don't know and thus cannot<br>
> > review.<br></div></blockquote><div><br></div><div>The only super-posix property I remember is that poll() returns whenever the process receives a signal. (ppoll does not exist)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">
> Arf... What parts seem dubious?<br>
<br>
</div>In my world:<br>
* Signal handlers are (unfortunately) per-process, not per-thread.<br></blockquote><div><br></div><div>Yes, unfortunately. This can indeed lead to issues.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


* Setting thread keys to zero is pointless.<br></blockquote><div><br></div><div>Indeed, but not an issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


* POSIX thread functions are not async-signal-safe, meaning they are not<br>
defined within signal handlers.<br></blockquote><div><br></div><div>Thus many FIXME and 'Why?' comments^^</div><div>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.</div>

<div>Maybe futexes are the way to go, but my knowledge of them is even worse than that of pthread^^</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

* pthread_setcancelstate() is not a cancellation point.<br></blockquote><div><br></div><div>OK, my bad. Slight misunderstanding/misreading of the API back then. Easy to remove the cancellation point here :)</div><div><br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I also don't understand where cancellation cleanup handlers (vlc_cleanup_push<br>
and friends) are dealt with.</blockquote><div><br></div><div>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.</div></div><div><br>

</div><div>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.</div><div>Btw, cancellation on Android is probably one of the worst ideas we could ever have ;-)</div>

<br>Best,<div><div><br clear="all"><br>-- <br>Jean-Philippe André<br><br>
</div></div>