On 12/04/2015 07:51 AM, Ira Cooper wrote: > >>>> >>>> why not use storage in the client_t instead of thread local? >>> >>> It comes down to the use case. For Samba, the right spot is almost >>> certainly the fd, because lease keys are a per-handle (which we map to >>> fd) property. >>> >>> client_t is a horror show, due to race conditions between threads, IMHO. >> >> If there are known races, should we not address that? Got a bug that >> explains it in more detail? > > Niels, > > For samba, if we do multi-threaded open, Kaleb's proposal is a > race-condition. I haven't gone through every use of client_t and seen > if it is racy. > > The race here is pretty simple: > > Thread 1: Sets lease_id > Thread 2: Sets lease_id > Thread 1: Opens file. (wrong lease_id) > > If these two threads represent requests from different clients, client_t > won't work, unless there's a client_t per-thread. client_t is, as one might guess from the name, per client (connection). If smbd has a single connection, then there's a single client_t for it. > > For global things on the connection, client_t is fine, and appropriate. > For this? No. > > This is a property per-open, and belongs in the glfs_fd and glfs_object, > IMHO. > > Thanks, > > -Ira > -- Kaleb _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
