Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Wed, 2013-01-09 at 10:06 +0800, David Xu wrote: > [...] > >>> This code won't work, as I said, after the signal handler returned, > >>> kernel will copy the signal mask contained in ucontext into kernel > >>> space, and use it in feature signal delivering. > >>> > >>> The code should be modified as following: > >>> > >>> void handler(int signum, siginfo_t *info, ucontext_t *uap) > >>> { > >>> ... > >>> > >>> if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { > >>> sigaddset(&uap->uc_sigmask, signum); > >> > >> Hmmm, this seems unlikely because the signal handler is operating in > >> user mode and has no access to kernel-mode variables. > > > > Well, it turns out that your suggestion was correct. > > > > I did some more searching and found another similar suggestion, so I > > gave it a whirl, and it works. > > > > Now, my problem is that Jeremy Allison thinks that it is a fugly hack. > > This means that I will probably have big problems getting a patch for > > this into Samba. > > > > I guess a couple of questions I have now are: > > > > 1. Is this the same for all versions of FreeBSD since Posix RT Signals > > were introduced? > > > > I have checked source code, and found from FreeBSD 7.0, RT signal is > supported, and aio code uses signal queue. > > > 2. Which (interpretation of which) combination of standards require such > > an approach? > > > > > The way I introduced is standard: > http://pubs.opengroup.org/onlinepubs/007904975/functions/sigaction.html > > I quoted some text here: > > When a signal is caught by a signal-catching function installed by > sigaction(), a new signal mask is calculated and installed for the > duration of the signal-catching function (or until a call to either > sigprocmask() or sigsuspend() is made). This mask is formed by taking > the union of the current signal mask and the value of the sa_mask for > the signal being delivered [XSI] [Option Start] unless SA_NODEFER or > SA_RESETHAND is set, [Option End] and then including the signal being > delivered. If and when the user's signal handler returns normally, the > original signal mask is restored. > > ... > > When the signal handler returns, the receiving thread resumes execution > at the point it was interrupted unless the signal handler makes other > arrangements. If longjmp() or _longjmp() is used to leave the signal > handler, then the signal mask must be explicitly restored. > > This volume of IEEE Std 1003.1-2001 defines the third argument of a > signal handling function when SA_SIGINFO is set as a void * instead of a > ucontext_t *, but without requiring type checking. New applications > should explicitly cast the third argument of the signal handling > > function to ucontext_t *. > ^ > > --- > > The above means third parameter is pointing to ucontext_t which is used > to restored the previously interrupted context, the context contains > a signal mask which is also restored. > http://pubs.opengroup.org/onlinepubs/007904975/basedefs/ucontext.h.html OK, thank you for that. Jeremy agrees that this is a portable approach, at least across Linux, FreeBSD and Solaris. We will try to get a fix into Samba to do it the correct way. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On 1/9/13 7:21 AM, Richard Sharpe wrote: On Tue, 2013-01-08 at 09:20 -0800, Adrian Chadd wrote: On 8 January 2013 08:15, Richard Sharpe wrote: On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: .. or you could abstract it out a bit and use freebsd's aio_waitcomplete() or kqueue aio notification. It'll then behave much saner. Yes, going forward that is what I want to do ... this would work nicely with a kqueue back-end for Samba's tevent subsystem, and if someone has not already written such a back end, I will have to do so, I guess. Embrace FreeBSD's nice asynchronous APIs for doing things! You know you want to! (Then, convert parts of samba over to use grand central dispatch... :-) Seriously though - I was doing network/disk IO using real time signals what, 10 + years ago on Linux and it plain sucked. AIO + kqueue + waitcomplete is just brilliant. kqueue for signal delivery is also just brilliant. Just saying. The problem with a fully event-driven approach is that it will not work, it seems to me. Eventually, you find something that is not async and then you have to go threaded. (Because handling multiple clients in one process is very useful and you do not want client-A's long-running op preventing client-B's short-running op from being serviced.) Then, you run into problems like Posix's insistence that all threads in a process must use the same credentials (ie, uid and gids must be the same across all threads), although there is a hack on Linux to work around this behind glibc's back. The best implementation of an async framework I've seen is the one that Alan Cox and friends wrote in the code they sold to IronPort/Cisco. It'd be nice if we could get that extracted out and donated/included into something generally available.. even had a #ifdef Linux code path.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Tue, 2013-01-08 at 09:20 -0800, Adrian Chadd wrote: > On 8 January 2013 08:15, Richard Sharpe wrote: > > On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: > >> .. or you could abstract it out a bit and use freebsd's > >> aio_waitcomplete() or kqueue aio notification. > >> > >> It'll then behave much saner. > > > > Yes, going forward that is what I want to do ... this would work nicely > > with a kqueue back-end for Samba's tevent subsystem, and if someone has > > not already written such a back end, I will have to do so, I guess. > > Embrace FreeBSD's nice asynchronous APIs for doing things! You know you want > to! > > (Then, convert parts of samba over to use grand central dispatch... :-) > > Seriously though - I was doing network/disk IO using real time signals > what, 10 + years ago on Linux and it plain sucked. AIO + kqueue + > waitcomplete is just brilliant. kqueue for signal delivery is also > just brilliant. Just saying. The problem with a fully event-driven approach is that it will not work, it seems to me. Eventually, you find something that is not async and then you have to go threaded. (Because handling multiple clients in one process is very useful and you do not want client-A's long-running op preventing client-B's short-running op from being serviced.) Then, you run into problems like Posix's insistence that all threads in a process must use the same credentials (ie, uid and gids must be the same across all threads), although there is a hack on Linux to work around this behind glibc's back. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Tue, 2013-01-08 at 22:24 -0500, Daniel Eischen wrote: > On Tue, 8 Jan 2013, Daniel Eischen wrote: > > > On Tue, 8 Jan 2013, Richard Sharpe wrote: > > > >> [ ... ] > >> > >> Well, it turns out that your suggestion was correct. > >> > >> I did some more searching and found another similar suggestion, so I > >> gave it a whirl, and it works. > >> > >> Now, my problem is that Jeremy Allison thinks that it is a fugly hack. > >> This means that I will probably have big problems getting a patch for > >> this into Samba. > > > > I don't understand why JA thinks this is a hack. Their current > > method doesn't work, or at least isn't portable. I've tried this > > on Solaris 10, and it works just as it does in FreeBSD. Test > > program included after signature. > > > > $ ./test_sigprocmask > > Sending signal 16 > > Got signal 16, blocked: true > > Blocking signal 16 using method 0 > > Handled signal 16, blocked: false > > > > Sending signal 16 > > Got signal 16, blocked: true > > Blocking signal 16 using method 1 > > Handled signal 16, blocked: true > > Weird - I just tested it on Linux (2.6.18-238.el5) and it works > the same as FreeBSD and Solaris. Am I misunderstanding something? > Is it possible that Samba's code is broken on all platforms? It is possible :-) AIO is off by default in configure. Then, when you switch it on in configure you have to switch it on in the smb.conf. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Tue, 8 Jan 2013, Daniel Eischen wrote: On Tue, 8 Jan 2013, Richard Sharpe wrote: [ ... ] Well, it turns out that your suggestion was correct. I did some more searching and found another similar suggestion, so I gave it a whirl, and it works. Now, my problem is that Jeremy Allison thinks that it is a fugly hack. This means that I will probably have big problems getting a patch for this into Samba. I don't understand why JA thinks this is a hack. Their current method doesn't work, or at least isn't portable. I've tried this on Solaris 10, and it works just as it does in FreeBSD. Test program included after signature. $ ./test_sigprocmask Sending signal 16 Got signal 16, blocked: true Blocking signal 16 using method 0 Handled signal 16, blocked: false Sending signal 16 Got signal 16, blocked: true Blocking signal 16 using method 1 Handled signal 16, blocked: true Weird - I just tested it on Linux (2.6.18-238.el5) and it works the same as FreeBSD and Solaris. Am I misunderstanding something? Is it possible that Samba's code is broken on all platforms? -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On 2013/01/09 11:14, Daniel Eischen wrote: On Tue, 8 Jan 2013, Richard Sharpe wrote: [ ... ] Well, it turns out that your suggestion was correct. I did some more searching and found another similar suggestion, so I gave it a whirl, and it works. Now, my problem is that Jeremy Allison thinks that it is a fugly hack. This means that I will probably have big problems getting a patch for this into Samba. I don't understand why JA thinks this is a hack. Their current method doesn't work, or at least isn't portable. I've tried this on Solaris 10, and it works just as it does in FreeBSD. Test program included after signature. $ ./test_sigprocmask Sending signal 16 Got signal 16, blocked: true Blocking signal 16 using method 0 Handled signal 16, blocked: false Sending signal 16 Got signal 16, blocked: true Blocking signal 16 using method 1 Handled signal 16, blocked: true Yeah, people think that signal handler is normal code, this is a misunderstanding, in fact, it really works like an interrupt service routine. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Tue, 8 Jan 2013, Richard Sharpe wrote: [ ... ] Well, it turns out that your suggestion was correct. I did some more searching and found another similar suggestion, so I gave it a whirl, and it works. Now, my problem is that Jeremy Allison thinks that it is a fugly hack. This means that I will probably have big problems getting a patch for this into Samba. I don't understand why JA thinks this is a hack. Their current method doesn't work, or at least isn't portable. I've tried this on Solaris 10, and it works just as it does in FreeBSD. Test program included after signature. $ ./test_sigprocmask Sending signal 16 Got signal 16, blocked: true Blocking signal 16 using method 0 Handled signal 16, blocked: false Sending signal 16 Got signal 16, blocked: true Blocking signal 16 using method 1 Handled signal 16, blocked: true -- DE #include #include #include #include #include #define SIGNAL_TO_USE SIGUSR1 static int got_signal = 0; static int method = 0; static char * signal_blocked_str(sigset_t *set) { if (sigismember(set, SIGNAL_TO_USE)) return ("true"); else return ("false"); } static void sighandler(int sig, int code, ucontext_t *ucp) { sigset_t set; sigprocmask(SIG_SETMASK, NULL, &set); printf("Got signal %d, blocked: %s\n", SIGNAL_TO_USE, signal_blocked_str(&set)); printf("Blocking signal %d using method %d\n", SIGNAL_TO_USE, method); if (method == 0) { sigaddset(&set, SIGNAL_TO_USE); sigprocmask(SIG_SETMASK, &set, NULL); } else sigaddset(&ucp->uc_sigmask, SIGNAL_TO_USE); got_signal = 1; } int main(int argc, char **argv) { sigset_t mask; struct sigaction act; /* Install the handler. */ sigemptyset(&act.sa_mask); sigaddset(&act.sa_mask, SIGNAL_TO_USE); act.sa_handler = sighandler; act.sa_flags = SA_SIGINFO; assert(sigaction(SIGNAL_TO_USE, &act, NULL) == 0); /* Unblock the signal. */ sigemptyset(&mask); sigaddset(&mask, SIGNAL_TO_USE); sigprocmask(SIG_UNBLOCK, &mask, NULL); printf("Sending signal %d\n", SIGNAL_TO_USE); kill(getpid(), SIGNAL_TO_USE); while (got_signal == 0) { sleep(1); } sigprocmask(SIG_SETMASK, NULL, &mask); printf("Handled signal %d, blocked: %s\n\n", SIGNAL_TO_USE, signal_blocked_str(&mask)); method = 1; printf("Sending signal %d\n", SIGNAL_TO_USE); kill(getpid(), SIGNAL_TO_USE); while (got_signal == 0) { sleep(1); } sigprocmask(SIG_SETMASK, NULL, &mask); printf("Handled signal %d, blocked: %s\n", SIGNAL_TO_USE, signal_blocked_str(&mask)); return (0); } ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On 2013/01/09 07:14, Richard Sharpe wrote: On Tue, 2013-01-08 at 08:14 -0800, Richard Sharpe wrote: On Tue, 2013-01-08 at 15:02 +0800, David Xu wrote: On 2013/01/08 14:33, Richard Sharpe wrote: On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: On 2013/01/08 09:27, Richard Sharpe wrote: Hi folks, I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 and I want to check if the assumptions made by the original coder are correct. Essentially, the code queues a number of AIO requests (up to 100) and specifies an RT signal to be sent upon completion with siginfo_t. These are placed into an array. The code assumes that when handling one of these signals, if it has already received N such siginfo_t structures, it can BLOCK further instances of the signal while these structures are drained by the main code in Samba. However, my debugging suggests that if a bunch of signals have already been queued, you cannot block those undelivered but already queued signals. I am certain that they are all being delivered to the main thread and that they keep coming despite the code trying to stop them at 64 (they get all the way up to the 100 that were queued.) Can someone confirm whether I have this correct or not? I am curious that how the code BLOCKs the signal in its signal handler ? AFAIK, after signal handler returned, original signal mask is restored, and re-enables the signal delivering, unless you change it in ucontext.uc_sigmask. It does try to block the signals in the signal handler using the following code (in the signal handler): if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { /* we've filled the info array - block this signal until these ones are delivered */ sigset_t set; sigemptyset(&set); sigaddset(&set, signum); sigprocmask(SIG_BLOCK, &set, NULL); However, I also added pthread_sigmask with the same parameters to see if that made any difference and it seemed not to. This code won't work, as I said, after the signal handler returned, kernel will copy the signal mask contained in ucontext into kernel space, and use it in feature signal delivering. The code should be modified as following: void handler(int signum, siginfo_t *info, ucontext_t *uap) { ... if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { sigaddset(&uap->uc_sigmask, signum); Hmmm, this seems unlikely because the signal handler is operating in user mode and has no access to kernel-mode variables. Well, it turns out that your suggestion was correct. I did some more searching and found another similar suggestion, so I gave it a whirl, and it works. Now, my problem is that Jeremy Allison thinks that it is a fugly hack. This means that I will probably have big problems getting a patch for this into Samba. I guess a couple of questions I have now are: 1. Is this the same for all versions of FreeBSD since Posix RT Signals were introduced? I have checked source code, and found from FreeBSD 7.0, RT signal is supported, and aio code uses signal queue. 2. Which (interpretation of which) combination of standards require such an approach? The way I introduced is standard: http://pubs.opengroup.org/onlinepubs/007904975/functions/sigaction.html I quoted some text here: When a signal is caught by a signal-catching function installed by sigaction(), a new signal mask is calculated and installed for the duration of the signal-catching function (or until a call to either sigprocmask() or sigsuspend() is made). This mask is formed by taking the union of the current signal mask and the value of the sa_mask for the signal being delivered [XSI] [Option Start] unless SA_NODEFER or SA_RESETHAND is set, [Option End] and then including the signal being delivered. If and when the user's signal handler returns normally, the original signal mask is restored. ... When the signal handler returns, the receiving thread resumes execution at the point it was interrupted unless the signal handler makes other arrangements. If longjmp() or _longjmp() is used to leave the signal handler, then the signal mask must be explicitly restored. This volume of IEEE Std 1003.1-2001 defines the third argument of a signal handling function when SA_SIGINFO is set as a void * instead of a ucontext_t *, but without requiring type checking. New applications should explicitly cast the third argument of the signal handling function to ucontext_t *. ^ --- The above means third parameter is pointing to ucontext_t which is used to restored the previously interrupted context, the context contains a signal mask which is also restored. http://pubs.opengroup.org/onlinepubs/007904975/basedefs/ucontext.h.html Regards, David Xu ___ freebsd-hackers@f
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Tue, 2013-01-08 at 08:14 -0800, Richard Sharpe wrote: > On Tue, 2013-01-08 at 15:02 +0800, David Xu wrote: > > On 2013/01/08 14:33, Richard Sharpe wrote: > > > On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: > > >> On 2013/01/08 09:27, Richard Sharpe wrote: > > >>> Hi folks, > > >>> > > >>> I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 > > >>> and I want to check if the assumptions made by the original coder are > > >>> correct. > > >>> > > >>> Essentially, the code queues a number of AIO requests (up to 100) and > > >>> specifies an RT signal to be sent upon completion with siginfo_t. > > >>> > > >>> These are placed into an array. > > >>> > > >>> The code assumes that when handling one of these signals, if it has > > >>> already received N such siginfo_t structures, it can BLOCK further > > >>> instances of the signal while these structures are drained by the main > > >>> code in Samba. > > >>> > > >>> However, my debugging suggests that if a bunch of signals have already > > >>> been queued, you cannot block those undelivered but already queued > > >>> signals. > > >>> > > >>> I am certain that they are all being delivered to the main thread and > > >>> that they keep coming despite the code trying to stop them at 64 (they > > >>> get all the way up to the 100 that were queued.) > > >>> > > >>> Can someone confirm whether I have this correct or not? > > >>> > > >> > > >> I am curious that how the code BLOCKs the signal in its signal handler ? > > >> AFAIK, after signal handler returned, original signal mask is restored, > > >> and re-enables the signal delivering, unless you change it in > > >> ucontext.uc_sigmask. > > > > > > It does try to block the signals in the signal handler using the > > > following code (in the signal handler): > > > > > > if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { > > > /* we've filled the info array - block this signal until > > > these ones are delivered */ > > > sigset_t set; > > > sigemptyset(&set); > > > sigaddset(&set, signum); > > > sigprocmask(SIG_BLOCK, &set, NULL); > > > > > > However, I also added pthread_sigmask with the same parameters to see if > > > that made any difference and it seemed not to. > > > > > > > This code won't work, as I said, after the signal handler returned, > > kernel will copy the signal mask contained in ucontext into kernel > > space, and use it in feature signal delivering. > > > > The code should be modified as following: > > > > void handler(int signum, siginfo_t *info, ucontext_t *uap) > > { > > ... > > > > if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { > > sigaddset(&uap->uc_sigmask, signum); > > Hmmm, this seems unlikely because the signal handler is operating in > user mode and has no access to kernel-mode variables. Well, it turns out that your suggestion was correct. I did some more searching and found another similar suggestion, so I gave it a whirl, and it works. Now, my problem is that Jeremy Allison thinks that it is a fugly hack. This means that I will probably have big problems getting a patch for this into Samba. I guess a couple of questions I have now are: 1. Is this the same for all versions of FreeBSD since Posix RT Signals were introduced? 2. Which (interpretation of which) combination of standards require such an approach? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
libevent doesn't do disk IO. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Jan 8, 2013, at 9:20 AM, Adrian Chadd wrote: > On 8 January 2013 08:15, Richard Sharpe wrote: >> On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: >>> .. or you could abstract it out a bit and use freebsd's >>> aio_waitcomplete() or kqueue aio notification. >>> >>> It'll then behave much saner. >> >> Yes, going forward that is what I want to do ... this would work nicely >> with a kqueue back-end for Samba's tevent subsystem, and if someone has >> not already written such a back end, I will have to do so, I guess. > > Embrace FreeBSD's nice asynchronous APIs for doing things! You know you want > to! > > (Then, convert parts of samba over to use grand central dispatch... :-) > > Seriously though - I was doing network/disk IO using real time signals > what, 10 + years ago on Linux and it plain sucked. AIO + kqueue + > waitcomplete is just brilliant. kqueue for signal delivery is also > just brilliant. Just saying. Or just use libevent to abstract away kqueues/inotify/etc? Samba isn't just for freebsd... Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On 8 January 2013 08:15, Richard Sharpe wrote: > On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: >> .. or you could abstract it out a bit and use freebsd's >> aio_waitcomplete() or kqueue aio notification. >> >> It'll then behave much saner. > > Yes, going forward that is what I want to do ... this would work nicely > with a kqueue back-end for Samba's tevent subsystem, and if someone has > not already written such a back end, I will have to do so, I guess. Embrace FreeBSD's nice asynchronous APIs for doing things! You know you want to! (Then, convert parts of samba over to use grand central dispatch... :-) Seriously though - I was doing network/disk IO using real time signals what, 10 + years ago on Linux and it plain sucked. AIO + kqueue + waitcomplete is just brilliant. kqueue for signal delivery is also just brilliant. Just saying. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: > .. or you could abstract it out a bit and use freebsd's > aio_waitcomplete() or kqueue aio notification. > > It'll then behave much saner. Yes, going forward that is what I want to do ... this would work nicely with a kqueue back-end for Samba's tevent subsystem, and if someone has not already written such a back end, I will have to do so, I guess. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Tue, 2013-01-08 at 15:02 +0800, David Xu wrote: > On 2013/01/08 14:33, Richard Sharpe wrote: > > On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: > >> On 2013/01/08 09:27, Richard Sharpe wrote: > >>> Hi folks, > >>> > >>> I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 > >>> and I want to check if the assumptions made by the original coder are > >>> correct. > >>> > >>> Essentially, the code queues a number of AIO requests (up to 100) and > >>> specifies an RT signal to be sent upon completion with siginfo_t. > >>> > >>> These are placed into an array. > >>> > >>> The code assumes that when handling one of these signals, if it has > >>> already received N such siginfo_t structures, it can BLOCK further > >>> instances of the signal while these structures are drained by the main > >>> code in Samba. > >>> > >>> However, my debugging suggests that if a bunch of signals have already > >>> been queued, you cannot block those undelivered but already queued > >>> signals. > >>> > >>> I am certain that they are all being delivered to the main thread and > >>> that they keep coming despite the code trying to stop them at 64 (they > >>> get all the way up to the 100 that were queued.) > >>> > >>> Can someone confirm whether I have this correct or not? > >>> > >> > >> I am curious that how the code BLOCKs the signal in its signal handler ? > >> AFAIK, after signal handler returned, original signal mask is restored, > >> and re-enables the signal delivering, unless you change it in > >> ucontext.uc_sigmask. > > > > It does try to block the signals in the signal handler using the > > following code (in the signal handler): > > > > if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { > > /* we've filled the info array - block this signal until > >these ones are delivered */ > > sigset_t set; > > sigemptyset(&set); > > sigaddset(&set, signum); > > sigprocmask(SIG_BLOCK, &set, NULL); > > > > However, I also added pthread_sigmask with the same parameters to see if > > that made any difference and it seemed not to. > > > > This code won't work, as I said, after the signal handler returned, > kernel will copy the signal mask contained in ucontext into kernel > space, and use it in feature signal delivering. > > The code should be modified as following: > > void handler(int signum, siginfo_t *info, ucontext_t *uap) > { > ... > > if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { > sigaddset(&uap->uc_sigmask, signum); Hmmm, this seems unlikely because the signal handler is operating in user mode and has no access to kernel-mode variables. I guess I will just have to read the code. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
.. or you could abstract it out a bit and use freebsd's aio_waitcomplete() or kqueue aio notification. It'll then behave much saner. adrian On 7 January 2013 22:26, Richard Sharpe wrote: > On Mon, 2013-01-07 at 22:24 -0500, Daniel Eischen wrote: >> On Mon, 7 Jan 2013, Richard Sharpe wrote: >> >> > Hi folks, >> > >> > I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 >> > and I want to check if the assumptions made by the original coder are >> > correct. >> > >> > Essentially, the code queues a number of AIO requests (up to 100) and >> > specifies an RT signal to be sent upon completion with siginfo_t. >> > >> > These are placed into an array. >> > >> > The code assumes that when handling one of these signals, if it has >> > already received N such siginfo_t structures, it can BLOCK further >> > instances of the signal while these structures are drained by the main >> > code in Samba. >> > >> > However, my debugging suggests that if a bunch of signals have already >> > been queued, you cannot block those undelivered but already queued >> > signals. >> > >> > I am certain that they are all being delivered to the main thread and >> > that they keep coming despite the code trying to stop them at 64 (they >> > get all the way up to the 100 that were queued.) >> > >> > Can someone confirm whether I have this correct or not? >> >> If true, could they not use sigwaitinfo() from a separate >> thread instead and just bypass having to use a signal >> handler altogether? That thread can either call sigwaitinfo() >> when it is ready to receive more signals, or block on a >> semaphore/CV/whatever while events are being processed. > > So, I guess that what I want is something that will continue to work for > both Linux and FreeBSD with minimal code divergence ... > > I guess I need to write a simpler program to check what the deal is. > > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On 2013/01/08 15:02, David Xu wrote: On 2013/01/08 14:33, Richard Sharpe wrote: On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: On 2013/01/08 09:27, Richard Sharpe wrote: Hi folks, I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 and I want to check if the assumptions made by the original coder are correct. Essentially, the code queues a number of AIO requests (up to 100) and specifies an RT signal to be sent upon completion with siginfo_t. These are placed into an array. The code assumes that when handling one of these signals, if it has already received N such siginfo_t structures, it can BLOCK further instances of the signal while these structures are drained by the main code in Samba. However, my debugging suggests that if a bunch of signals have already been queued, you cannot block those undelivered but already queued signals. I am certain that they are all being delivered to the main thread and that they keep coming despite the code trying to stop them at 64 (they get all the way up to the 100 that were queued.) Can someone confirm whether I have this correct or not? I am curious that how the code BLOCKs the signal in its signal handler ? AFAIK, after signal handler returned, original signal mask is restored, and re-enables the signal delivering, unless you change it in ucontext.uc_sigmask. It does try to block the signals in the signal handler using the following code (in the signal handler): if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { /* we've filled the info array - block this signal until these ones are delivered */ sigset_t set; sigemptyset(&set); sigaddset(&set, signum); sigprocmask(SIG_BLOCK, &set, NULL); However, I also added pthread_sigmask with the same parameters to see if that made any difference and it seemed not to. This code won't work, as I said, after the signal handler returned, kernel will copy the signal mask contained in ucontext into kernel space, and use it in feature signal delivering. The code should be modified as following: void handler(int signum, siginfo_t *info, ucontext_t *uap) { ... if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { sigaddset(&uap->uc_sigmask, signum); ... here, sigprocmask call should be removed. Not that this code may only work in single thread mode, if there are multiple threads in the process, kernel is free to deliver the signal to any thread which is not masking it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On 2013/01/08 14:33, Richard Sharpe wrote: On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: On 2013/01/08 09:27, Richard Sharpe wrote: Hi folks, I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 and I want to check if the assumptions made by the original coder are correct. Essentially, the code queues a number of AIO requests (up to 100) and specifies an RT signal to be sent upon completion with siginfo_t. These are placed into an array. The code assumes that when handling one of these signals, if it has already received N such siginfo_t structures, it can BLOCK further instances of the signal while these structures are drained by the main code in Samba. However, my debugging suggests that if a bunch of signals have already been queued, you cannot block those undelivered but already queued signals. I am certain that they are all being delivered to the main thread and that they keep coming despite the code trying to stop them at 64 (they get all the way up to the 100 that were queued.) Can someone confirm whether I have this correct or not? I am curious that how the code BLOCKs the signal in its signal handler ? AFAIK, after signal handler returned, original signal mask is restored, and re-enables the signal delivering, unless you change it in ucontext.uc_sigmask. It does try to block the signals in the signal handler using the following code (in the signal handler): if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { /* we've filled the info array - block this signal until these ones are delivered */ sigset_t set; sigemptyset(&set); sigaddset(&set, signum); sigprocmask(SIG_BLOCK, &set, NULL); However, I also added pthread_sigmask with the same parameters to see if that made any difference and it seemed not to. This code won't work, as I said, after the signal handler returned, kernel will copy the signal mask contained in ucontext into kernel space, and use it in feature signal delivering. The code should be modified as following: void handler(int signum, siginfo_t *info, ucontext_t *uap) { ... if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { sigaddset(&uap->uc_sigmask, signum); ... here, sigprocmask call should be removed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: > On 2013/01/08 09:27, Richard Sharpe wrote: > > Hi folks, > > > > I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 > > and I want to check if the assumptions made by the original coder are > > correct. > > > > Essentially, the code queues a number of AIO requests (up to 100) and > > specifies an RT signal to be sent upon completion with siginfo_t. > > > > These are placed into an array. > > > > The code assumes that when handling one of these signals, if it has > > already received N such siginfo_t structures, it can BLOCK further > > instances of the signal while these structures are drained by the main > > code in Samba. > > > > However, my debugging suggests that if a bunch of signals have already > > been queued, you cannot block those undelivered but already queued > > signals. > > > > I am certain that they are all being delivered to the main thread and > > that they keep coming despite the code trying to stop them at 64 (they > > get all the way up to the 100 that were queued.) > > > > Can someone confirm whether I have this correct or not? > > > > I am curious that how the code BLOCKs the signal in its signal handler ? > AFAIK, after signal handler returned, original signal mask is restored, > and re-enables the signal delivering, unless you change it in > ucontext.uc_sigmask. It does try to block the signals in the signal handler using the following code (in the signal handler): if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { /* we've filled the info array - block this signal until these ones are delivered */ sigset_t set; sigemptyset(&set); sigaddset(&set, signum); sigprocmask(SIG_BLOCK, &set, NULL); However, I also added pthread_sigmask with the same parameters to see if that made any difference and it seemed not to. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Mon, 2013-01-07 at 22:24 -0500, Daniel Eischen wrote: > On Mon, 7 Jan 2013, Richard Sharpe wrote: > > > Hi folks, > > > > I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 > > and I want to check if the assumptions made by the original coder are > > correct. > > > > Essentially, the code queues a number of AIO requests (up to 100) and > > specifies an RT signal to be sent upon completion with siginfo_t. > > > > These are placed into an array. > > > > The code assumes that when handling one of these signals, if it has > > already received N such siginfo_t structures, it can BLOCK further > > instances of the signal while these structures are drained by the main > > code in Samba. > > > > However, my debugging suggests that if a bunch of signals have already > > been queued, you cannot block those undelivered but already queued > > signals. > > > > I am certain that they are all being delivered to the main thread and > > that they keep coming despite the code trying to stop them at 64 (they > > get all the way up to the 100 that were queued.) > > > > Can someone confirm whether I have this correct or not? > > If true, could they not use sigwaitinfo() from a separate > thread instead and just bypass having to use a signal > handler altogether? That thread can either call sigwaitinfo() > when it is ready to receive more signals, or block on a > semaphore/CV/whatever while events are being processed. So, I guess that what I want is something that will continue to work for both Linux and FreeBSD with minimal code divergence ... I guess I need to write a simpler program to check what the deal is. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Mon, 7 Jan 2013, Richard Sharpe wrote: Hi folks, I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 and I want to check if the assumptions made by the original coder are correct. Essentially, the code queues a number of AIO requests (up to 100) and specifies an RT signal to be sent upon completion with siginfo_t. These are placed into an array. The code assumes that when handling one of these signals, if it has already received N such siginfo_t structures, it can BLOCK further instances of the signal while these structures are drained by the main code in Samba. However, my debugging suggests that if a bunch of signals have already been queued, you cannot block those undelivered but already queued signals. I am certain that they are all being delivered to the main thread and that they keep coming despite the code trying to stop them at 64 (they get all the way up to the 100 that were queued.) Can someone confirm whether I have this correct or not? If true, could they not use sigwaitinfo() from a separate thread instead and just bypass having to use a signal handler altogether? That thread can either call sigwaitinfo() when it is ready to receive more signals, or block on a semaphore/CV/whatever while events are being processed. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On 2013/01/08 09:27, Richard Sharpe wrote: Hi folks, I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 and I want to check if the assumptions made by the original coder are correct. Essentially, the code queues a number of AIO requests (up to 100) and specifies an RT signal to be sent upon completion with siginfo_t. These are placed into an array. The code assumes that when handling one of these signals, if it has already received N such siginfo_t structures, it can BLOCK further instances of the signal while these structures are drained by the main code in Samba. However, my debugging suggests that if a bunch of signals have already been queued, you cannot block those undelivered but already queued signals. I am certain that they are all being delivered to the main thread and that they keep coming despite the code trying to stop them at 64 (they get all the way up to the 100 that were queued.) Can someone confirm whether I have this correct or not? I am curious that how the code BLOCKs the signal in its signal handler ? AFAIK, after signal handler returned, original signal mask is restored, and re-enables the signal delivering, unless you change it in ucontext.uc_sigmask. Regards, David Xu ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"