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

[John Ogness]

Tushar wrote:
> 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. 

I was going through the changelogs to see what has been changed and
found the answer:

We used to have a problem that data was not being flushed to the file
for CLOSE events before the registered client would look at it. For
example, with Dazuko 2.0.6 (and earlier) we could have the file of size
1 byte. Then we use something like `echo "0" >> file` to append a second
byte. When the registered client received the CLOSE event and inspected
the file, only the first byte would be available because the data was
not yet flushed to the file.

To fix this problem, with Dazuko 2.1.0 we introduced a function
handle_event_as_readonly() to treat certain events as if Dazuko was not
interested in what the client had to say. Since a CLOSE event cannot be
blocked, it really doesn't matter what the client says about the event.
For this reason, Dazuko does not wait for a response before allowing the
process to complete.

This is why you see "cp" finish before your client answers. It is
because Dazuko actually doesn't care what your answer is and does not
wait for you.

Note to application developers: You should still always return the CLOSE
event anyway, or else you will have a memory leak.

John Ogness

-- 
Dazuko Maintainer