[Top][All Lists]

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

Re: [Dazuko-devel] dazuko 2.1.0 and blocking access for long time.

From: John Ogness
Subject: Re: [Dazuko-devel] dazuko 2.1.0 and blocking access for long time.
Date: Thu, 22 Sep 2005 20:34:51 +0200
User-agent: Debian Thunderbird 1.0.2 (X11/20050817)

Tushar wrote:
> I have observed that with dazuko 2.1.0, if access to kernel is not
> returned immediately with dazukoUnregister_TS function call, the process
> is not blocked.
> <snip code with CLOSE>
> So, if I cp to a monitored dir, cp ends before the statement "after
> sleep" is displayed. This happens only if dazuko 2.1.0 module is loaded,
> with dazuko 2.0.6, it works as expected.
>       Has any one experienced similar behavior? Is this is bug?


I am assuming you are using Linux 2.4 and you are only talking about the
ON_CLOSE event. For these events, Dazuko doesn't post the event until
after the kernel has performed the close(). This is because it doesn't
make sense to "block" a close. Most applications do not check the return
code from close(), which means it would lead to a file descriptor leak.
It is also true that flushing data to a file does not require a close().
This is why you can sleep on the CLOSE event, but the application doing
the closing will still be able to continue.

On the other hand, ON_OPEN events are posted before the kernel opens the
file. This gives registered applications a chance to block the open,
which is something useful since most applications will check the return
value of an open() to see if it was successful.

However, this is nothing new to 2.1.0, so I do not understand why this
would be any different for 2.0.6. I also do not see what
dazukoUnregister() has to do with your example.

John Ogness

Dazuko Maintainer

reply via email to

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