packet_* => tstream glue
simo
idra at samba.org
Wed Nov 4 15:51:23 MST 2009
On Thu, 2009-11-05 at 09:25 +1100, Andrew Bartlett wrote:
> On Wed, 2009-11-04 at 23:07 +0100, Volker Lendecke wrote:
> > On Thu, Nov 05, 2009 at 08:39:43AM +1100, Andrew Bartlett wrote:
> > > The use of 'send' and 'recv' in the tsocket code is really quite
> > > confusing. In this case, it means 'start' and 'conclude' (or 'finish')
> > > the asynchronous operations, rather than to send() and recv() packets.
> > >
> > > Would it be at all possible to change those names? It really bends the
> > > mind a bit too much.
> >
> > Please don't. tsocket_recv_send and tsocket_recv_recv is
> > indeed confusing, but all the other async functions use
> > _send and _recv.
>
> Which I think shows that, while it makes sense for 'send and recv' a
> packet, that is is a really poor choice of naming pattern for a general
> infrastructure.
>
> > With the async functions you usually don't
> > use these low-level direct async counterparts of the sendto
> > and recvfrom syscalls much anyway, in Samba3 we mostly use
> > the writev and read_packet which are much more powerful.
>
> I still disagree that the pattern justifies such a ridiculous name. Do
> you have any other suggestions? I really think what we have now is
> impossible to explain to others.
What's hard to explain in a convention ?
A single bad case is not enough to justify changing a lot of code and a
solid convention through all our code.
Put there a comment if you really need to.
Simo.
--
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>
More information about the samba-technical
mailing list