Re: Is it possible to block pending queued RealTime signals (AIO originating)?

2013-01-09 Thread Richard Sharpe
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)?

2013-01-09 Thread Julian Elischer

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)?

2013-01-09 Thread Richard Sharpe
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)?

2013-01-08 Thread Richard Sharpe
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)?

2013-01-08 Thread Daniel Eischen

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)?

2013-01-08 Thread David Xu

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)?

2013-01-08 Thread Daniel Eischen

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)?

2013-01-08 Thread David Xu

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)?

2013-01-08 Thread Richard Sharpe
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)?

2013-01-08 Thread Adrian Chadd
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)?

2013-01-08 Thread Garrett Cooper
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)?

2013-01-08 Thread Adrian Chadd
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)?

2013-01-08 Thread Richard Sharpe
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)?

2013-01-08 Thread Richard Sharpe
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)?

2013-01-08 Thread Adrian Chadd
.. 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)?

2013-01-07 Thread David Xu

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)?

2013-01-07 Thread David Xu

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)?

2013-01-07 Thread Richard Sharpe
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)?

2013-01-07 Thread Richard Sharpe
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)?

2013-01-07 Thread Daniel Eischen

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)?

2013-01-07 Thread David Xu

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"