On Monday 16 April 2007, Daniel Jacobowitz wrote: > - It calls sleep expecting a cancellation point at nanosleep. But > libc.so's sleep.c has "libc_hidden_proto(nanosleep)" which means it > always calls the libc.so version, never the wrapped version in > libpthread.so that's a cancellation point. Delete that line from > sleep.c and usleep.c and now sleep/usleep start acting like > cancellation points.
i need to finish up my local cancellation handler rewrite and get it merged ... > - It never terminates. This is the bit I've got a question about - I > can't see how it ever would terminate. Main returns, so we end up in > exit. The manager thread sends a cancellation signal to every > thread. But because we're already in a cancellation handler, SIGRT_1 > is blocked. So we'll spin forever in exit. This is one of the > reasons you're not supposed to have infinite loops in your > cancellation handlers. it did when i wrote it ;) and it does on glibc ... but then again, this is a good example of why implementing POSIX threads via signals sucks a lot > So... Mike, you added this - how did it terminate? :-) it was originally developed against uClibc-0.9.26 ... interaction between libc and libpthread and libc itself has changed dramatically since ... so the test can probably be disabled pending tweaks since the issue it tests for i know ive forward ported and merged into trunk -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
