site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Organization: Swedish Institute of Computer Science On May 30, 2006, at 4:54 AM, Per Mildner wrote: On May 8, 2006, at 12:59 PM, Andre-John Mas wrote:
On May 8, 2006, at 12:45 PM, Andre-John Mas wrote:
Could anyone tell me whether pthread_cancel() is planned to be implemented properly in a future version of Darwin? From what I understand the current implementation does not conform to the posix implementation.
If you compile with _APPLE_C_SOURCE, _POSIX_C_SOURCE or _XOPEN_SOURCE, the implementation should behave as you want. Thanks. Just one question are these for my applications or for compiling the kernel?
This is when compiling user-level programs. matt. What exectly is supposed to change when setting _APPLE_C_SOURCE? I realize that this causes a new version of pthread_cancel to be called. However, the real problem is that the POSIX mandated thread cancellation points are missing, e.g. in read and write. static int exit_status = EXIT_FAILURE; void * func(void *arg) { char buf; exit_status = EXIT_SUCCESS; return NULL; } int main(void) { pthread_t t; void *retval; assert(!pthread_create(&t, NULL, func, NULL)); sleep(1); assert(!pthread_cancel(t)); assert(!pthread_join(t, &retval)); assert(PTHREAD_CANCELED == retval); calling read...called read()==1 calling read.. HANGS HERE until an additional <CR> entered wormwood2:~/sicstus/sicstus4wormwood2 perm$ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On 8-May-06, at 16:08 , Matt Watson wrote: As you point out, a different version of certain pthread routines is used when _APPLE_C_SOURCE is set. I can't reproduce what you are seeing. Do you have a self-contained source example exhibiting the problem? The following program works properly when built with _APPLE_C_SOURCE on 10.4.6: .. snip ... Adding a sleep before the call to pthread_cancel makes the program hang. One guess would be that there are cancellation points within the thread startup code. In the below transcript you can see how it hangs even though it apparently gets cancelled as soon as read() gets some input. wormwood2:~/sicstus/sicstus4wormwood2 perm$ uname -a Darwin wormwood2.sics.se 8.6.0 Darwin Kernel Version 8.6.0: Tue Mar 7 16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power Macintosh powerpc wormwood2:~/sicstus/sicstus4wormwood2 perm$ cat foo.c #include <assert.h> #include <pthread.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> while (1) { ssize_t res; fprintf(stderr, "calling read..");fflush(stderr); res = read(STDIN_FILENO, &buf, 1); fprintf(stderr, ".called read()==%ld\n", (long)res);fflush(stderr); } return exit_status; } # The first <CR> below is for passing the line to shell (all this is done in bash from within xemacs) wormwood2:~/sicstus/sicstus4wormwood2 perm$ gcc -D_APPLE_C_SOURCE foo.c && ./a.out <CR> calling read.. HANGS UNTIL an additional <CR> entered wormwood2:~/sicstus/sicstus4wormwood2 perm$ gcc -D_APPLE_C_SOURCE foo.c && ./a.out <CR> <CR> This email sent to site_archiver@lists.apple.com