No smb_raw_search_next in smb_cliraw.h

[Volker Lendecke]

On Tue, Jul 01, 2014 at 10:14:44PM +0200, Stef Bon wrote:
> Yes thank you for the info.
> 
> Yes I'm using libnfs by Ronnie Sahlberg.
> 
> I understand the send - done - recv construction.
> But how does the receiving work?
> 
> So far asynchronous io was for me one eventloop, which watches the fd
> to the remote server (using epoll for example). Then when data is
> available for reading, it reads the message (or a first part, a
> header) enough to determine the kind of message. When it finds a
> message id or something, it maps it to the requests (in a queue)
> waiting for a reply. When the right request is found, it gets a thread
> (from a pool) to process the reply.
> 
> Now I understand that the tevent library works different. As far as I
> can see for every request send it watches the fd for a result. It's
> "peeking" at the data when there is available at the fd, and checks
> it's the reply it's waiting for. When it is, it's reading the whole
> reply, and process that futher. It's possible to poll one fd with more
> than one epoll/poll/select instance.
> 
> Is my analysis correct?

Sounds correct, yes. All this mechanism is however deeply
hidden in our smb libraries. The tevent_req abstraction
works more around asynchronous computations that can be
multi-step. Yes, listening on sockets for readability and
writability is the essential part of it, but you don't focus
on that anymore so hard when programming with tevent_req.
That's the main point of tevent_req: Reacting to individual
socket readability events is just too clumsy. You want to
get as closely as possible to co-routines as you can get in
C. tevent_req is our proposal to do this.

Volker

-- 
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