Re: [Nfs-ganesha-devel] libntirpc thread local storage

2017-12-09 Thread William Allen Simpson
On 12/9/17 5:28 PM, Matt Benjamin wrote: I've already proposed we remove this.  No one is invested in it, I don't think. OK. I'll take a poke at it today. It makes sense that this is a good time to handle, as we've already made a major change to CLNT_CALL in this release.

Re: [Nfs-ganesha-devel] libntirpc thread local storage

2017-12-09 Thread Matt Benjamin
I've already proposed we remove this. No one is invested in it, I don't think. Matt On Dec 10, 2017 2:38 AM, "William Allen Simpson" < william.allen.simp...@gmail.com> wrote: > I've run into another TLS problem. It's been there since tirpc. > > Apparently, once upon a time, rpc_createerr was

[Nfs-ganesha-devel] libntirpc thread local storage

2017-12-09 Thread William Allen Simpson
I've run into another TLS problem. It's been there since tirpc. Apparently, once upon a time, rpc_createerr was a static global. It still says that in the man pages. When a client create function fails, they stash the error there, and return NULL for the CLIENT. Basically, you check for NULL,

Re: [Nfs-ganesha-devel] Stacked FSALs and fsal_export parameters and op_ctx

2017-12-09 Thread William Allen Simpson
On 12/8/17 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. With future async FSAL calls, it's going to stop working. We already have a