dazuko-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dazuko-devel] dazukofs-3.0.0 interrupted system calls


From: Frantisek Hrbata
Subject: Re: [Dazuko-devel] dazukofs-3.0.0 interrupted system calls
Date: Fri, 27 Feb 2009 09:34:24 +0100

On Fri, 27 Feb 2009 08:53:52 +0100
John Ogness <address@hidden> wrote:

> [ Sorry. I accidentally sent the last message while still writing
>   it. Here is my complete response. ]
> 
> On 2009-02-26, Frantisek Hrbata <address@hidden> wrote:
> > I experimentally added support for dazukofs to our upcoming avg8
> > because I would like to make some performance comparison between
> > dazukofs and avflt.
> 
> Nice. It would be great if you could post the results of your tests
> here.
>
> > After dazukofs integration to our scanner I have noticed that
> > dazukofs_get_access returns a lots of -EINTR. I am using dazukofs in
> > a multi-threaded scanner and this error occurs only when more then
> > one thread is used. I wrote a simple showfiles_mt application using
> > dazukofs in several threads just to check out if the problem is in
> > my integration or in dazukofs. As I found out I can easily reproduce
> > this behavior with showfiles_mt.
> 
> I am running a multi-threaded application without any such
> problems. However, my implementation is slightly different then
> yours. I will illustrate the difference here using a diff-like
> approach.
> 
> int main(void)
> {
>      ...
> -    signal(SIGTERM, sigterm);
> -    signal(SIGINT, sigterm);
> +    sigset_t sigset;
> +
> +    /* catch TERM,INT,HUP signals */
> +    signal(SIGTERM, sigterm);
> +    signal(SIGINT, sigterm);
> +    signal(SIGHUP, sigterm);
> +
> +    /* ignore SIGUSR1 (only used by threads) */
> +    if (sigemptyset(&sigset) == 0) {
> +       sigaddset(&sigset, SIGUSR1);
> +       sigprocmask(SIG_BLOCK, &sigset, NULL);
> +    }
> 
> So far the only difference is catching the HUP signal and explicitly
> ignoring USR1. (HUP is the signal X sends if the X environment is
> closed.)
> 
> void *thread_proc(void *data)
> {
>      ...
> -    sigemptyset(&sigset);
> -    sigaddset(&sigset, SIGINT);
> -    sigaddset(&sigset, SIGTERM);
> -    pthread_sigmask(SIG_BLOCK, &sigset, NULL);
> -    sigaddset(&sigset, SIGUSR1);
> -    pthread_sigmask(SIG_UNBLOCK, &sigset, NULL);
> +    /* ignore TERM,INT,HUP signals within threads */
> +    if (sigemptyset(&sigset) == 0) {
> +       sigaddset(&sigset, SIGTERM);
> +       sigaddset(&sigset, SIGINT);
> +       sigaddset(&sigset, SIGHUP);
> +       pthread_sigmask(SIG_BLOCK, &sigset, NULL);
> +    }
> +
> +    /* catch USR1 signal within threads */
> +    if (sigemptyset(&sigset) == 0) {
> +       sigaddset(&sigset, SIGUSR1);
> +       pthread_sigmask(SIG_UNBLOCK, &sigset, NULL);
> +    }
> 
> Again there is the difference with the HUP signal. But I also notice
> that you don't clear the set before setting up the unblock. So you are
> effectively unblocking everything you had already set to
> block. I suspect that is your problem.

You are right about the forgotten sigempty call before unblocking
SIGUSR1, but I think that this little game with signals doesn't 
affect the described behavior at all. Even if there is no signal
handling it should run just fine. Yes it would be problem to
stop threads, but this should have no affect on dazukofs_get_access
during normal run. Anyway I reworked the signal handling as proposed in
your comments, but as I expected, the result is the same. I am testing
it on amd64 dual core architecture.

Linux humpdell 2.6.28 #1 SMP PREEMPT Thu Dec 25 17:39:00 CET 2008
x86_64 GNU/Linux

> > Also there is just a simple single process example shipped within
> > dazukofs package so I am not sure if I am using it right.
> 
> I will add a multi-threaded showfiles to the next release package.

That would be great.

> John Ogness
> 

-FH




reply via email to

[Prev in Thread] Current Thread [Next in Thread]