I'm on the opposite end. I'm not in favor of passing op_ctx needlessly
to every function in Ganesha.
Any useful threading system must have some form of TLS.
Daniel
On 12/08/2017 10:13 AM, Matt Benjamin wrote:
I'd like to see this use of TLS as a "hidden parameter" replaced
regardless. It has been a source of bugs, and locks us into a
pthreads execution model I think needlessly.
Matt
On Fri, Dec 8, 2017 at 10:07 AM, Frank Filz <ffilz...@mindspring.com> wrote:
On 12/7/17 7:54 PM, Frank Filz wrote:
Stacked FSALs often depend on op_ctx->fsal_export being set.
We also have lots of FSAL methods that take the fsal_export as a
parameter.
The latter sounds better.
Now that we know every single thread local storage access involves a hidden
lock/unlock sequence in glibc "magically" invoked by the linker, it would be
better to remove as many TLS references as possible!
After all, too many lock/unlock are a real performance issue.
Perhaps we should pass op_ctx as the parameter instead.
I thought the lock was only to create the TLS variable, and not on every
reference.
Frank
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
