[PATCH] Add thread safety to socket_wrapper
Anoop C S
anoopcs at autistici.org
Thu Mar 1 08:21:39 UTC 2018
On Thu, 2018-02-22 at 14:51 -0800, Jeremy Allison via samba-technical wrote:
> On Thu, Feb 22, 2018 at 12:30:16PM +0100, Volker Lendecke via samba-technical wrote:
> > On Thu, Feb 22, 2018 at 12:03:11PM +0100, Andreas Schneider via samba-technical wrote:
> > > On Thursday, 22 February 2018 11:46:36 CET Volker Lendecke wrote:
> > > > On Thu, Feb 22, 2018 at 11:28:30AM +0100, Andreas Schneider via samba-
> > >
> > > technical wrote:
> > > > > the attached patchset adds thread safety support to socket_wrapper. It is
> > > > > the ground work for fd passing to test multichannel and smbdirect in
> > > > > selftest.
> > > > >
> > > > > It would be great to get additional review. If I don't hear anything till
> > > > > next week Wednesday I'm going to push it.
> > > >
> > > > Not that it's relevant for the cwrap project, still my 2ct:
> > > >
> > > > What's the point of SOCKET_INFO_GET_REFCOUNT? It's even more
> > > > characters in source code. Also, SOCKET_INFO_GET hides the reference
> > > > to a global variable. Why? These macros make the code harder to read,
> > > > at least for me. Macros can have their place, but what's the reasoning
> > > > here?
> > >
> > > we implemented it that way, that in future steps, we just have to change
> > > SOCKET_INFO_GET() and not modify the complete source code again and again. We
> > > wanted to keep changes minimal if possible. Yes, currently it is a global
> > > variable but that will change. I hope our TODO list (appended at the end)
> > > helps you to understand the master plan behind it.
> > To me, helper functions are always preferrable. They give improved
> > error checking, and less hassle with variable name conflicts. See
> > https://en.wikipedia.org/wiki/Hygienic_macro for info on that. C in
> > contrast to scheme just does not have hygienic macros. Helper
> > functions also allow for anonymous structures when added to a separate
> > module.
> Andreas, I have to admit, moving the macro's to functions
> would make much more sense, and also prevent erroneous
> use of the macro's (functions at least will do argument
> type checking).
> If you don't have time, I might have a go at changing this
> patchset to function rather than macro based code.
I have made changes accordingly. See the attached patch set.
> For long-term maintanence, it really is a better choice.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 79793 bytes
Desc: not available
More information about the samba-technical