I wonder whether pushing the complexity of tevent into the VFS was a good idea?

[Richard Sharpe]

On Sat, Nov 10, 2012 at 4:02 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> On Sat, 2012-11-10 at 10:05 -0800, Richard Sharpe wrote:
>> Hi folks,
>>
>> I notice that there are now SMB_VFS_PREAD_SEND and SMB_VFS_PREAD_RECV
>> VFS interfaces to support AIO, which seems to push the complexity of
>> tevent into the VFS.
>>
>> Wouldn't, say, an explicit callback model for such things have been
>> easier to handle for those who have to implement VFS modules?
>>
>> By callback model, I mean that the AIO pread etc interfaces be handed
>> a callback, which could simply be aio_pread_smb1_done from the current
>> code (with some changes to remove the tevent dependencies.)
>>
>> I guess I am trying to figure out what the benefits of the approach of
>> pushing complexity into the VFS are that outweighed the advantages of
>> a simpler model.
>>
>> (Sigh, I am going to have to update the VFS document :-()
>
> One of the challenges is that for each different callback modal (and in
> many ways that's exactly what tevent is) we have to translate between
> them (if possible) and both teach the rules it follows (specifically how
> it gets to know to call the callback) and re-learn the lessons we have
> embodied in tevent.
>
> I also find tevent hard to get my head around, but I think it's better
> that we stick to that pattern, now we have it.

Yes, I have been getting my head around it ... one of the difficulties
is all these functions all over the place that are called
wb_simple_trans_send, which of course, does no such thing. It queues
an event that will call the function wb_simple_trans_send, which
queues an event that will call the function wb_req_write_send which
actually queues an event to call writev_send which queues an event to
call an underlying writev_send function ... which just might call
writev or something like it ... and then there are all these call back
routines merrily calling callback routines and calling routines
misleadingly called xxx_recv ...

(and the name struct tevent_req *tdgram_recvfrom_send is confusing
enough but tdgram_recvfrom_recv is worse)

Still, I have to get my head around it so I will press on.

> In short, while I understand where you are coming from, I'm hesitant to
> have another situation like ldb, which has an async modal that isn't
> tevent, and which (due to this and other issues, like a primary use case
> that is pure sync in any case) has therefore essentially been unable to
> be used async in Samba.

Yes. I can understand that. However, up until now the contract that
the VFS has provided, I think, is that all calls have the feeling of
standard function calls.

Now, I happen to think that the thread-pool idea that AIO has been
implemented on recently is a good idea and wonder if VFS module
writers can take advantage of that when writing their own VFS modules.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)