[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha6-954-gbb7e6f0

[Stefan (metze) Metzmacher]

Hi Tridge,

>  > I'm in progress to fix the whole problem correctly, by fixing the socket
>  > abstraction. The function socket_get_fd() is stupid and breaks the
>  > abstraction.
> 
> socket_get_fd() is used for more than just the event code, it's also
> used for things like setting socket options. I think it will take a
> fair bit more work to remove it.

It's only used with event_add_fd() and set_blocking(),
with tsocket all sockets will be non-blocking and event_add_fd() is hidden.

Also the current socket code has a socket_set_option() function.

>  > The caller should give a tevent_context to the socket layer and
>  > callbacks for read and write, it's up to the socket layer how to trigger
>  > them.
> 
> How will those socket layers do that triggering? The timed event
> method is ugly (and hard to get error handling right),

That depends on the type of socket, but I can't see why the timed event
method is ugly (the timed event method is much, much better than neested
event_loop_once() calls). and the error handling should also not too hard.

> and the
> "multiple recv" method that I put in the packet code (ie. "unreliable
> select") can only really be done at the place where the data is
> packetised, not below, or you will end up with moving the buffered
> data up one level without solving the problem.
> 
>  > The packet.c code will also be obsoleted by a generic
>  > tsocket_send[to]_queue_send/recv() and tsocket_recv_pkt_send/recv() code.
> 
> The primary motivation for the packet code wasn't to provide the
> read/write layer, but to 'packetise' a stream.

I know, but for the "send" case it is really just a queue
and tsocket_send[to]_queue_send/recv() will provide exactly the same
functionality.

For the "recv" case tsocket_recv_pkt_send/recv() will also get
"is_this_complete" callback and finishes on error or when a full packet
buffer is availabe via tsocket_recv_pkt_recv(). The functionality
is really the same as with the current packet layer.

So the new function just split the send and recv cases and make use
of the generic tevent_req _send/_recv() logic for async tasks.
I plan to first keep the packet layer, but base it on top of the new
functions. So that we don't need to change all of our current code.

> We had lots of bits of
> code that tried to do the rather tricky task of buffering correctly so
> that you grab just the right amount of data from a stream to form one
> parsable lump of data, so it made sense to add a single layer that
> handles all that complexity, relying only on a "is this a complete
> packet" function from the protocol specific code.
>
> I really like the packet.c functionality at the moment. It eliminates
> a lot of complex processing from all of the protocol layers, and it is
> flexible enough to handle all the protocols we've had to deal
> with. I'd be reluctant to throw that away.

I absolutely agree, we will keep the functionality and just change the
interface to it.

We really need to unify the way async function calls work in samba.
It makes it much easier if everybody needs to learn only one way.

It's also an important step in bringing source3 and source4 more closely
together. My motivation is, that I want to use our async cldap library
in source3/ instead using the sync calls in libads/cldap.c. And now
things like this are really possible, because source3/ and source4/ both
use the lib/tevent interface now.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20090219/613ee8ba/signature.bin