[PATCH] Add thread safety to socket_wrapper

[Andreas Schneider]

On Thursday, 22 February 2018 23:51:48 CET Jeremy Allison 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'm out of office today. I agree and also think that probably having a 
funciton is better. I didn't reach Anoop, I think he would look into it.


	Andreas