libsmbclient for Samba4: initial design issues

[Michael B Allen]

On Fri, 12 Aug 2005 15:25:03 -0400
derrell at samba.org wrote:

>  - Allow for an asynchronous interface with event notification.

Just to give you some other ideas consider an interface like this:

  int client_sendrecv(struct client *client,
        struct request *request,
        struct response *response,
        int flags);

where this sends the request and populates the response. I don't think
this is any different from what you have now but then add a "NOWAIT"
flag that indicates that the request should be written or queued but the
call may return before the response is received. Then at a later time
the function can be called again *without* the NOWAIT flag at which point
it will block until the response has been recieved if it hasn't already.

The nice thing about this is that the API is "small" because it's the
same function used by all other non-async code. By just adding a flag
you get async behavior.

>  - Keep the interface "pure"; i.e. no global or static variables.  Handles
>    (context variables, if you like) will be allocated and passed into each of
>    the functions.  This "may" allow the client library to be thread safe,
>    depending upon on what lies beneath it, but also meets the documented goals
>    of Samba4 and provides a clean interface.

By "pure" I believe "reentrant" is the prevailing term. At this point
code that is not fully reentrant is just broken. But there are an
infinate number of levels of "thread safe". At the highest level of
protection would be allowing multiple threads to *work on the same
file*.  That's pretty odd really (and unnecessary if you have an async
option). I think protected data shared by multiple client contexts is
more practical. Meaning you could allow multiple threads to work on the
same client context but not on the same file. Or perhaps each thread is
required to create there own client context.

Mike