dbwrap_record_watch_send/recv

[Volker Lendecke]

On Fri, Feb 17, 2012 at 10:06:55AM +0100, Stefan (metze) Metzmacher wrote:
> > Under
> > 
> > http://git.samba.org/?p=vl/samba.git/.git;a=shortlog;h=refs/heads/dbwrap_record_watch
> > 
> > Comments?
> 
> That looks like a really nice infrastructure!
> It'll really help a lot to cleanup our code.
> 
> I have just a few cosmetic remarks:
> 
> When first reading the name 'msg_stream', I'm a bit confused, because
> it could imply that we're using some sort of stream sockets.
> After reading the code my impression that 'msg_channel' could be a
> better name,
> but I'm not a native speaker...(Native speakers please comment on this)
> What do you think about this?

Maybe you're right. Others?

> Did you intend to add msg_write_send/recv also based on a 'struct
> msg_stream' (or whatever name it endup with)
> later?

msg_stream right now is bound to a msg_type. This would not
be appropriate for sending messages I think.

> For msg_stream_send/recv I propose to add '_setup' in the function name
> 'msg_stream_setup_send/recv'.

Ok, sounds reasonable.

> Why does dbwrap_record_watch_send() use the sync msg_stream() function
> instead of msg_stream_send/recv?

I had that first. But it does not work, because you do not
want to unlock the record you want to watch before you are
sure to receive all messages correctly, i.e. you need to
wait for the msg_stream. But this would mean that we enter
the main event loop with a locked record, something which I
would REALLY like to avoid.

Acquiring a msg_stream is async right now because we have to
register a SRVID with ctdb. This in theory can block, sure.
But I am planning to severely tune ctdb_conn anyway.
Possibly I would have just one single socket into ctdb and
hide this fact behind the API. We could then cache the
registrations and discard messages that we have registered
for with ctdb but for which we don't have any
ctdb_msg_stream's for right now. If we did that, normally
acquiring the msg_stream would in fact be non-blocking.

This is a dirty corner of that patchset, but I did not find
a clean way around that problem yet. If you have any good
ideas, I would be very interested to hear about them.

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