March 2012 - Darwin-dev - lists.apple.com

Re: Missing in sigaction
by Nat! 29 Mar '12

29 Mar '12

Am 28.03.2012 um 09:07 schrieb Tilghman Lesher: > > You should be able to achieve the same effect (without the identified > race condition) simply by adding SA_NODEFER to your sa_flags. > _______________________________________________ OK, now this has been helpful and I think I now have a consistent theory about it: If a signal arrives on a signal that is blocked, it's stored as pending. If another signal arrives while the other is still pending it gets dropped, because the kernel doesn't want to stack signals indefinetely. At this point though the contained information in struct __siginfo is almost useless, because - for instance - only one of the possibly different sending pids could be identified. Therefore it's actually better to not receive a struct __siginfo at all. With SA_NODEFER, signals aren't blocked so the struct __siginfo can be passed unmodified. If that were the case then the absence of struct __siginfo would actually be a valuable clue. Ciao Nat! --------------------------------------------------- Java's the worst thing -- good way to make things a tenth as fast as they should be. - J. Carmack _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Missing in sigaction
by Wade Tregaskis 28 Mar '12

28 Mar '12

> 1/10th of a second is the maximum amount of time each thread is given > to execute before the kernel preempts the thread, to allow another > thread (or process) to execute. It's heavily ingrained in all > Unix-based systems, a somewhat arbitrary decision made in the 1960s by > Dennis Ritchie, the father of Unix. There have been attempts by > others to modify that value, with results that caused performance to > suffer, and the takeaway is that nobody has tried to modify the > maximum timeslot since. That's not true. Many systems (Linux, BSDs, etc) use a variety of other intervals - 100Hz, 250Hz, 1kHz, 4kHz, etc. It's often tuneable. There are sysctls etc for retrieving it - you should never hard-code an assumption. It's also not a maximum, or strictly speaking a minimum. In the absence of contention (and blocking, obviously) a thread will remain on a core indefinitely. It may also be interrupted sooner than this designated interval for various high-priority threads. It's really only meant to say "for N contending threads with equal priority, give them each roughly X much time per N*X time period". Even that is arguable. > When you wait in a signal handler longer than > the maximum length of a context switch, other processes (and not other > threads in the same process) will get multiple timeslots, but the > process in which a signal handler sleeps will be stuck, unable to do > anything else, because _nothing_ in that process other than other > signal handlers (if not blocked) can be invoked while that signal > handler is still running. Also not true, as was pointed out. I'm also not sure it makes sense to to even consider the scheduler interval. It's kind of an archaic concept. There's also no guarantee that you'll receive signals promptly, or that it's at the start of a quantum. There's no guarantee that you won't be signalled, put onto the signal stack, but then pre-empted immediately to another thread before you actual run the first instruction of your signal handler. If there were bugs in signal handling, pre-emption would be a likely place for them, but they would be just that - bugs. Any assertion that you somehow have to avoid pre-emption in a signal handler is just bizarre in its impossibility. None of this is to say that you should sit around signal handlers for a long time - there are many reasons not to, including the fact that you're interrupting your own code, potentially on the main thread, so you've no idea what could be timing out in the meantime. But you should be able to, technically, if you choose. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Missing in sigaction
by Greg Parker 28 Mar '12

28 Mar '12

On Mar 28, 2012, at 7:43 AM, Tilghman Lesher <tilghman(a)meg.abyt.es> wrote: > 1/10th of a second is the maximum amount of time each thread is given > to execute before the kernel preempts the thread, to allow another > thread (or process) to execute. It's heavily ingrained in all > Unix-based systems, a somewhat arbitrary decision made in the 1960s by > Dennis Ritchie, the father of Unix. There have been attempts by > others to modify that value, with results that caused performance to > suffer, and the takeaway is that nobody has tried to modify the > maximum timeslot since. When you wait in a signal handler longer than > the maximum length of a context switch, other processes (and not other > threads in the same process) will get multiple timeslots, but the > process in which a signal handler sleeps will be stuck, unable to do > anything else, because _nothing_ in that process other than other > signal handlers (if not blocked) can be invoked while that signal > handler is still running. I don't know much about UNIX history, but Darwin doesn't work this way. When a signal arrives, one thread handles the signal and other threads in that process continue unimpeded. (I'd also expect Darwin to pre-empt threads much faster than 1/10s, and I'd expect "timeslots" to be a wild oversimplification on a multiprocessor system.) % % clang test.c && ./a.out signal second thread still running second thread still running second thread still running second thread still running second thread still running signal done % cat test.c #include <stdio.h> #include <signal.h> #include <unistd.h> #include <pthread.h> void *fn(void *arg) { while (1) { printf("second thread still running\n"); sleep(1); } return arg; } void handler(int arg) { write(STDOUT_FILENO, "signal\n", 7); sleep(5); write(STDOUT_FILENO, "signal done\n", 7+5); } int main() { pthread_t th; pthread_create(&th, NULL, &fn, NULL); signal(SIGUSR1, &handler); kill(getpid(), SIGUSR1); } _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Missing in sigaction
by Tilghman Lesher 28 Mar '12

28 Mar '12

On Wed, Mar 28, 2012 at 3:28 AM, Nat! <nat(a)mulle-kybernetik.com> wrote: > Am 28.03.2012 um 09:15 schrieb Tilghman Lesher: >> On Tue, Mar 27, 2012 at 5:50 PM, Nat! <nat(a)mulle-kybernetik.com> wrote: >>> Am 27.03.2012 um 22:22 schrieb Tilghman Lesher: >>>> On Tue, Mar 27, 2012 at 1:57 PM, Nat! <nat(a)mulle-kybernetik.com> wrote: >>>>> instead of many words, here's the output of two program runs once with a sleep( 2) - as in seconds, not as in man - commented in and out. What I believe this demonstrates, is that on Darwin (Kernel Version 10.8.0), blocked signal information is lost, which is incovenient. gdb has a similiar problem. >>>>> >>>>> Or it shows that I am misunderstanding something ;) >>>>> >>>>> The problem is not that the signal is occurring less often, that's expected, but that the struct __siginfo has trouble remembering things. >>>> >>>> You really should read the manpage for sigaction, in particular, the >>>> section that reads: >>>> >>>> "In general though, signal handlers should do little more than set a >>>> flag; most other actions are not safe." >>>> >>>> Note, also, that printf() is not in the list of "safe" functions to >>>> call. Thus your call to p_log is defined as not safe. While sleep() >>>> is safe to call, it also violates one of the cardinal rules of signal >>>> handlers -- do only what is necessary to flag that a signal occurred, >>>> and do not take more time than is necessary. The actual handling of >>>> what the signal represents should be done in a main thread. >>> >>> Tilghman, do you really think printf will magically erase struct __siginfo.si_pid ahead of printf even being called ? >> >> No, I think you shouldn't be calling sleep(3) inside a signal handler. >> Ever. Any time the execution of a signal handler lasts longer than a >> single context switch (1/10th of a second), you are asking for >> trouble. I also pointed out that your use of printf(3) is indicative >> that you haven't understood the sigaction(2) documentation. > > It's more indicative, that you haven't really understood the code or the problem. > > sigaction(2) says in plain words: > > The following functions are either reentrant or not interruptible by sig- > nals and are async-signal safe. Therefore applications may invoke them, > without restriction, from signal-catching functions: > > Base Interfaces: > > ... sleep() ... > > > "Therefore applications may invoke them, without restriction, from signal-catching functions" > > That is without restriction, even if you really feel differently. And the next sentence is, as quoted above is: >>>> "In general though, signal handlers should do little more than set a >>>> flag; most other actions are not safe." > OTOH, there is absolutely no mention of a magical 1/10 s rule in the documentation. Where did you get that from ? 1/10th of a second is the maximum amount of time each thread is given to execute before the kernel preempts the thread, to allow another thread (or process) to execute. It's heavily ingrained in all Unix-based systems, a somewhat arbitrary decision made in the 1960s by Dennis Ritchie, the father of Unix. There have been attempts by others to modify that value, with results that caused performance to suffer, and the takeaway is that nobody has tried to modify the maximum timeslot since. When you wait in a signal handler longer than the maximum length of a context switch, other processes (and not other threads in the same process) will get multiple timeslots, but the process in which a signal handler sleeps will be stuck, unable to do anything else, because _nothing_ in that process other than other signal handlers (if not blocked) can be invoked while that signal handler is still running. Now, for your test process, this doesn't matter all that much, because it's not doing anything else. But it's a really bad habit to get into, because in a real process, you will prevent every other thread from running, including threads invoked by libraries and frameworks designed to make the application respond in expected ways. You _really_ need to take to heart the admonition that a signal handler should _only_ set a flag and _immediately_ return. -Tilghman _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Missing in sigaction
by Nat! 28 Mar '12

28 Mar '12

Am 28.03.2012 um 09:15 schrieb Tilghman Lesher: > On Tue, Mar 27, 2012 at 5:50 PM, Nat! <nat(a)mulle-kybernetik.com> wrote: >> Am 27.03.2012 um 22:22 schrieb Tilghman Lesher: >>> On Tue, Mar 27, 2012 at 1:57 PM, Nat! <nat(a)mulle-kybernetik.com> wrote: >>>> instead of many words, here's the output of two program runs once with a sleep( 2) - as in seconds, not as in man - commented in and out. What I believe this demonstrates, is that on Darwin (Kernel Version 10.8.0), blocked signal information is lost, which is incovenient. gdb has a similiar problem. >>>> >>>> Or it shows that I am misunderstanding something ;) >>>> >>>> The problem is not that the signal is occurring less often, that's expected, but that the struct __siginfo has trouble remembering things. >>> >>> You really should read the manpage for sigaction, in particular, the >>> section that reads: >>> >>> "In general though, signal handlers should do little more than set a >>> flag; most other actions are not safe." >>> >>> Note, also, that printf() is not in the list of "safe" functions to >>> call. Thus your call to p_log is defined as not safe. While sleep() >>> is safe to call, it also violates one of the cardinal rules of signal >>> handlers -- do only what is necessary to flag that a signal occurred, >>> and do not take more time than is necessary. The actual handling of >>> what the signal represents should be done in a main thread. >> >> Tilghman, do you really think printf will magically erase struct __siginfo.si_pid ahead of printf even being called ? > > No, I think you shouldn't be calling sleep(3) inside a signal handler. > Ever. Any time the execution of a signal handler lasts longer than a > single context switch (1/10th of a second), you are asking for > trouble. I also pointed out that your use of printf(3) is indicative > that you haven't understood the sigaction(2) documentation. It's more indicative, that you haven't really understood the code or the problem. sigaction(2) says in plain words: The following functions are either reentrant or not interruptible by sig- nals and are async-signal safe. Therefore applications may invoke them, without restriction, from signal-catching functions: Base Interfaces: ... sleep() ... "Therefore applications may invoke them, without restriction, from signal-catching functions" That is without restriction, even if you really feel differently. OTOH, there is absolutely no mention of a magical 1/10 s rule in the documentation. Where did you get that from ? Ciao Nat! ------------------------------------------------------ Ich selbst habe mich persönlich stets an den sittlichen Gepflogenheiten des Philisters beteiligt; nicht, weil ich ihnen Wert beigemessen hätte, sondern weil ich - vorwärts, immer mal wieder! - keinen Anlaß traf, mich von ihnen zu trennen. -- H. Mann _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Missing in sigaction
by Stephen J. Butler 28 Mar '12

28 Mar '12

On Wed, Mar 28, 2012 at 2:07 AM, Tilghman Lesher <tilghman(a)meg.abyt.es> wrote: > You should be able to achieve the same effect (without the identified > race condition) simply by adding SA_NODEFER to your sa_flags. Can't believe I missed that! I read it, but my mind was on UNBLOCK not DEFER. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Missing in sigaction
by Tilghman Lesher 28 Mar '12

28 Mar '12

On Tue, Mar 27, 2012 at 5:50 PM, Nat! <nat(a)mulle-kybernetik.com> wrote: > Am 27.03.2012 um 22:22 schrieb Tilghman Lesher: >> On Tue, Mar 27, 2012 at 1:57 PM, Nat! <nat(a)mulle-kybernetik.com> wrote: >>> instead of many words, here's the output of two program runs once with a sleep( 2) - as in seconds, not as in man - commented in and out. What I believe this demonstrates, is that on Darwin (Kernel Version 10.8.0), blocked signal information is lost, which is incovenient. gdb has a similiar problem. >>> >>> Or it shows that I am misunderstanding something ;) >>> >>> The problem is not that the signal is occurring less often, that's expected, but that the struct __siginfo has trouble remembering things. >> >> You really should read the manpage for sigaction, in particular, the >> section that reads: >> >> "In general though, signal handlers should do little more than set a >> flag; most other actions are not safe." >> >> Note, also, that printf() is not in the list of "safe" functions to >> call. Thus your call to p_log is defined as not safe. While sleep() >> is safe to call, it also violates one of the cardinal rules of signal >> handlers -- do only what is necessary to flag that a signal occurred, >> and do not take more time than is necessary. The actual handling of >> what the signal represents should be done in a main thread. > > Tilghman, do you really think printf will magically erase struct __siginfo.si_pid ahead of printf even being called ? No, I think you shouldn't be calling sleep(3) inside a signal handler. Ever. Any time the execution of a signal handler lasts longer than a single context switch (1/10th of a second), you are asking for trouble. I also pointed out that your use of printf(3) is indicative that you haven't understood the sigaction(2) documentation. > To make you feel better, appended is the same code, without printf, "surprisingly" with the same result. And if you remove the sleep() call, surprisingly, there's no issue. -Tilghman _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Missing in sigaction
by Tilghman Lesher 28 Mar '12

28 Mar '12

On Tue, Mar 27, 2012 at 11:03 PM, Stephen J. Butler <stephen.butler(a)gmail.com> wrote: > Because I'm bored, I spent a couple hours investigating this. If there > is a bug (and I'm not convinced there is -- there's a lot I don't know > about signal handling) then it's a bug when a SIGUSR1 arrives while > another SIGUSR1 is executing. Take the attached code, for example. > > First, I tried to not do anything you aren't supposed to do in the > signal handler. I was still seeing some dropped SIGUSR1s and missing > pids. After reading a bunch of man pages, headers, and IEEE specs, I > asked myself "What happens if I unblock SIGUSR1 while handling it?" > > Ahh ha, success! For me at least the attached code always handles all > signals, and preserves si_pid. There is a race condition in that you > could run into the previous problem if your signal arrives before > sigprocmask() is called. Of course, now you have to be extra careful > that your handler is re-entrant. You should be able to achieve the same effect (without the identified race condition) simply by adding SA_NODEFER to your sa_flags. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Missing in sigaction
by Stephen J. Butler 28 Mar '12

28 Mar '12

Because I'm bored, I spent a couple hours investigating this. If there is a bug (and I'm not convinced there is -- there's a lot I don't know about signal handling) then it's a bug when a SIGUSR1 arrives while another SIGUSR1 is executing. Take the attached code, for example. First, I tried to not do anything you aren't supposed to do in the signal handler. I was still seeing some dropped SIGUSR1s and missing pids. After reading a bunch of man pages, headers, and IEEE specs, I asked myself "What happens if I unblock SIGUSR1 while handling it?" Ahh ha, success! For me at least the attached code always handles all signals, and preserves si_pid. There is a race condition in that you could run into the previous problem if your signal arrives before sigprocmask() is called. Of course, now you have to be extra careful that your handler is re-entrant. My understanding is that blocked signals should be delivered when they are unblocked (ie: after the handler returns). I don't know why they aren't in this case. #include <sys/wait.h> #include <errno.h> #include <signal.h> #include <stdarg.h> #include <stdint.h> #include <stdio.h> #include <unistd.h> #define G_INFO_SIZE 32 uint32_t g_info_idx = 0; typedef struct { int si_signo; /* signal number */ int si_errno; /* errno association */ int si_code; /* signal code */ pid_t si_pid; /* sending process */ } g_info_t; g_info_t g_info[ G_INFO_SIZE ]; int g_info_wfd; sigset_t g_usr1_sigset; void handle_sigs( int signal, struct __siginfo *info, void *uap ) { uint8_t idx; pid_t wpid; switch (signal) { case SIGUSR1: sigprocmask( SIG_UNBLOCK, &g_usr1_sigset, NULL ); idx = __sync_fetch_and_add( &g_info_idx, 1 ) % G_INFO_SIZE; g_info[ idx ].si_signo = info->si_signo; g_info[ idx ].si_errno = info->si_errno; g_info[ idx ].si_code = info->si_code; g_info[ idx ].si_pid = info->si_pid; /* we can't do anything about errors here, just write * and hope for the best */ write( g_info_wfd, &idx, 1 ); sleep( 2 ); break; case SIGCHLD: while ((wpid = waitpid( -1, NULL, WNOHANG )) > 0) { idx = __sync_fetch_and_add( &g_info_idx, 1 ) % G_INFO_SIZE; g_info[ idx ].si_signo = SIGCHLD; g_info[ idx ].si_errno = 0; g_info[ idx ].si_code = 0; g_info[ idx ].si_pid = wpid; /* we can't do anything about errors here, just write * and hope for the best */ write( g_info_wfd, &idx, 1 ); } break; } } void pid_logf( const char *format, ... ) { va_list args; printf( "[%d] ", getpid() ); va_start( args, format ); vprintf( format, args ); va_end( args ); printf( "\n" ); } int do_test( void ) { pid_t child_pid; pid_logf( "Forking a child" ); child_pid = fork(); if (child_pid == -1) return -1; else if (child_pid != 0) return 0; /* inside the child now */ sigaction( SIGUSR1, (struct sigaction *)SIG_DFL, NULL ); sigaction( SIGCHLD, (struct sigaction *)SIG_DFL, NULL ); pid_logf( "Sending SIGUSR1 to %d", getppid() ); if (kill( getppid(), SIGUSR1 ) == -1) { pid_logf( "ERROR: kill returned %d", errno ); _exit( 1 ); } pid_logf( "Sleeping" ); sleep( 1 ); pid_logf( "Sending SIGUSR1 to %d", getppid() ); if (kill( getppid(), SIGUSR1 ) == -1) { pid_logf( "ERROR: kill returned %d", errno ); _exit( 1 ); } pid_logf( "Sleeping" ); sleep( 1 ); pid_logf( "Exiting" ); _exit( 0 ); } int main( void ) { struct sigaction sa; int pipe_fds[ 2 ] = { 0 }; int nchildren = 0; pid_logf( "Creating pipe" ); if (pipe( pipe_fds ) == -1) { pid_logf( "ERROR: pipe returned %d", errno ); return 1; } g_info_wfd = pipe_fds[ 1 ]; sigemptyset( &g_usr1_sigset ); sigaddset( &g_usr1_sigset, SIGUSR1 ); sigemptyset( &sa.sa_mask ); sa.sa_sigaction = handle_sigs; sa.sa_flags = SA_SIGINFO | SA_RESTART | SA_NOCLDSTOP; pid_logf( "Installing SIGUSR1 handler" ); if (sigaction( SIGUSR1, &sa, NULL ) == -1) { pid_logf( "ERROR: sigaction returned %d", errno ); return 1; } pid_logf( "Installing SIGCHLD handler" ); if (sigaction( SIGCHLD, &sa, NULL ) == -1) { pid_logf( "ERROR: sigaction returned %d", errno ); return 1; } if (do_test() == -1) { pid_logf( "ERROR: fork returned %d", errno ); return 1; } else ++nchildren; if (do_test() == -1) { pid_logf( "ERROR: fork returned %d", errno ); return 1; } else ++nchildren; while (nchildren > 0) { fd_set readset, errorset; uint8_t idx = 0; int nfds = 0; int ret = 0; FD_ZERO( &readset ); FD_ZERO( &errorset ); FD_SET( pipe_fds[ 0 ], &readset ); FD_SET( pipe_fds[ 0 ], &errorset ); if (pipe_fds[ 0 ] >= nfds) nfds = pipe_fds[ 0 ] + 1; pid_logf( "Waiting for a signal" ); ret = select( nfds, &readset, NULL, &errorset, NULL ); if (ret == -1) { if (errno != EINTR) { pid_logf( "ERROR: select returned %d", errno ); return 1; } } else if (ret > 0) { if (FD_ISSET( pipe_fds[ 0 ], &errorset )) { pid_logf( "ERROR: pipe is bad" ); return 1; } while ((ret = read( pipe_fds[ 0 ], &idx, 1 )) == 0); if (ret == -1) { pid_logf( "ERROR: read from pipe returned %d", errno ); } pid_logf( "signal %d from { %d, %d, %d, %d }", g_info[ idx ].si_signo, g_info[ idx ].si_signo, g_info[ idx ].si_errno, g_info[ idx ].si_code, g_info[ idx ].si_pid ); if (g_info[ idx ].si_signo == SIGCHLD) --nchildren; } } return 0; } _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Missing in sigaction
by Nat! 27 Mar '12

27 Mar '12

Am 27.03.2012 um 22:22 schrieb Tilghman Lesher: > On Tue, Mar 27, 2012 at 1:57 PM, Nat! <nat(a)mulle-kybernetik.com> wrote: >> instead of many words, here's the output of two program runs once with a sleep( 2) - as in seconds, not as in man - commented in and out. What I believe this demonstrates, is that on Darwin (Kernel Version 10.8.0), blocked signal information is lost, which is incovenient. gdb has a similiar problem. >> >> Or it shows that I am misunderstanding something ;) >> >> The problem is not that the signal is occurring less often, that's expected, but that the struct __siginfo has trouble remembering things. > > You really should read the manpage for sigaction, in particular, the > section that reads: > > "In general though, signal handlers should do little more than set a > flag; most other actions are not safe." > > Note, also, that printf() is not in the list of "safe" functions to > call. Thus your call to p_log is defined as not safe. While sleep() > is safe to call, it also violates one of the cardinal rules of signal > handlers -- do only what is necessary to flag that a signal occurred, > and do not take more time than is necessary. The actual handling of > what the signal represents should be done in a main thread. > > -Tilghman > Tilghman, do you really think printf will magically erase struct __siginfo.si_pid ahead of printf even being called ? To make you feel better, appended is the same code, without printf, "surprisingly" with the same result. Ciao Nat! #include <errno.h> #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> static void p_log( char *s) { printf( "%d: %s\n", getpid(), s); } static struct __siginfo memo; static void signal_action( int signal, struct __siginfo *info, void *data) { memo = *info; /// COMMENT-UNCOMMENT /// sleep( 2); } static void _test( void) { p_log( "fork"); if( ! fork()) { p_log( "kill"); kill( getppid(), SIGUSR1); p_log( "sleep"); sleep( 1); p_log( "kill"); kill( getppid(), SIGUSR1); p_log( "sleep"); sleep( 1); p_log( "_exit"); _exit( 0); } } int main( int argc, char *argv[]) { struct sigaction act; int status; sigemptyset( &act.sa_mask); act.__sigaction_u.__sa_sigaction = signal_action; act.sa_flags = SA_SIGINFO|SA_RESTART; p_log( "sigaction"); sigaction( SIGUSR1, &act, NULL); _test(); _test(); p_log( "wait"); while( wait( &status) == -1); p_log( "wait"); while( wait( &status) == -1); printf( "%d: memo = { %d, %d, %d, %d }\n", getpid(), memo.si_signo, memo.si_errno, memo.si_code, memo.si_pid); p_log( "_exit"); _exit( 0); } --------------------------------------------------- I learned that a cynic is the name given to people, who know what’s coming by people who don’t, and have regarded it as a compliment ever since. -- J. Watkinson _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0