No smb_raw_search_next in smb_cliraw.h

[Volker Lendecke]

On Sun, Jul 13, 2014 at 11:12:11AM +0200, Stef Bon wrote:
> As a described earlier, the tevent library is async because it use
> more than one eventloop on one filedescriptor.
> Different threads can use a construction like:
> 
> while ( ! request is done) {
> 
>      tevent_loop_once(..)
> 
> }
> 
> The function foo_done is called as callback, and set's the request as done.
> 
> This way it's possible to let the requesting thread to wait for data
> coming from the server, without blocking the connection. It's also
> possible to programm very easy timeouts. ;)
> 
> Now with io like fs event change request, it's not possible to make
> the requesting thread wait. It should wait forever, causing a blocking
> situation.

What exactly do you mean with "fs event change" here? What
API call do you make to receive those events?

> What works is that there is a special thread which watches the
> filedescriptor for replies to the fs change notify request.
> 
> You agree with me?

In general, we try to avoid threads. Even for async file I/O
we have used a forked process with good success in the past:
See vfs_aio_fork.c. Yes, this turned out to be too
heavy-weight, so we converted this to a tevent_req based
implementation with well-hidden threads using pthreadpool.

> The same counts for when the connection  is reset by the remote site.
> This event is not detected until the client sends a request, and
> connection problems are detected. These events should be detected by a
> special thread.

Our way to detect this is to use the normal Unix semantics:
A stream socket where the other end just disconnects becomes
readable and if you then do the read call, you get 0 bytes.
Very well suited for an async model.

With best regards,

Volker Lendecke

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de