This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
>>>>> On Mon, 17 Nov 2003 18:08:03 -0800, Ulrich Drepper <drepper@redhat.com> said: Uli> David Mosberger wrote: >> The one I mentioned: signal handler gets called in this code >> right before the _IO_flockfile(): >> _IO_FILE *_IO_acquire_lock_file \ __attribute__((cleanup >> (_IO_acquire_lock_fct))) \ = (_fp); \ _IO_flockfile >> (_IO_acquire_lock_file); >> and then the signal handler calls write(), which ends up getting >> cancelled. What prevents this from happening? Uli> Why should it be prevented? If you call write in a signal Uli> handler you either disable cancellation of live with it. Ah, I see. I guess that's OK as long as programmer's using pthread_cancel() are aware of this. Reading the POSIX description, it would not have occurred to me that calling a cancellable function from a (asynchronous) signal handler is effectively equivalent to enabling asynchronous cancellation. --david
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |