On December 4, 2015 at 8:25:10 AM, Niels de Vos (ndevos@xxxxxxxxxx) wrote: > Okay, so you meant to say that client_t "is a horror show" for this > particular use-case (lease_id). It indeed does not sound suitable to use > client_t here. > > I'm not much of a fan for using Thread Local Storage and would prefer to > see a more close to atomic way like my suggestion for compound > procedures in an other email in this thread. Got an opinion about that? I’m not a big fan of the thread-local storage approach either. It could work OK if there was a 1:1 mapping between threads and clients, but AFAIK neither Samba nor Ganesha works that way. For anything that doesn’t, we’re going to be making these calls *frequently* and they’re far from free. Adding extra arguments to each call is a pain[1], but it seems preferable in this case. [1] Yet another reason that a control-block API would have been preferable to a purely argument-based API, but I guess that’s water under the bridge. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
