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

[Tushar]

On Fri, 2005-09-23 at 00:04, John Ogness wrote:
> 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?
> 
> Hi,
> 
> 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
Yes. I still need to check using 2.6 kernel.
> 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.
Not understood. 
Event need to be posted only after real close, that I can understand.
But as per my understanding, things happens as follows,

int close_hook()
{
        ret=perform real close.
        call process that registered for scanning       
        return ret;
        
}
In above case, only after all process are done with the scanning,
control will return to user space. But in my case it happens before
that. Note that there is no issue of return code. 
        

> 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.
OK.
> 
> However, this is nothing new to 2.1.0, so I do not understand why this
At least, it happens with me.
> would be any different for 2.0.6. I also do not see what
> dazukoUnregister() has to do with your example.
Sorry for this. What I meant was dazukoReturnAccess_TS.
> 
> John Ogness
-- 
Regards,
Tushar
--------------------
It's not a problem, it's an opportunity for improvement. Lets improve.