13:38:37 <ndevos> #startmeeting
13:38:37 <zodbot> Meeting started Thu Dec  4 13:38:37 2014 UTC.  The chair is ndevos. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:38:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:38:46 <ndevos> #chair anoopcs poornimag
13:38:46 <zodbot> Current chairs: anoopcs ndevos poornimag
13:38:52 <ndevos> #topic http://review.gluster.org/#/c/9060/
13:39:03 <ndevos> anoopcs: yes, partially
13:39:59 <anoopcs> What do you think?
13:40:48 <ndevos> I think it is more acceptible that way
13:41:11 <ndevos> still, the mutex+cond in a different structure is a little strange, but that does fure too
13:41:13 <poornimag> okey
13:41:54 <poornimag> ok, the graph->active is not gaurded by fs->mutex, hence it is ok to be in different structures?
13:41:59 <ndevos> s/fure/fuse/
13:42:32 <ndevos> well, it isnt nice, but yes, it is ok to have in different structures
13:43:02 <poornimag> ok,
13:43:08 <ndevos> as long as graph->active (or should it be 'used' again?) is protected/notified by glfs->mutex/cond
13:43:34 <ndevos> that is where I think there is a bug in fuse, it does not protect graph->used correctly
13:43:44 <poornimag> yes agreed, may be we can use graph->used itself,
13:44:08 <ndevos> yes, I think so
13:44:11 <poornimag> but we don't need a mutex for using that variable as it only one thread that can modify that variable
13:44:13 <poornimag> ?
13:44:40 <poornimag> which will be the poller thread...,
13:45:07 <ndevos> the modification happens in notify() right?
13:45:15 <anoopcs> yes
13:45:39 <poornimag> yes, thats poller thread..,
13:46:17 <ndevos> I'd be more happy with having graph->used protected by glfs->mutex
13:46:30 <poornimag> ok..:)
13:46:54 <poornimag> yeah that can be done..,
13:47:27 <ndevos> you never know when something changes, and in case poller behaves differently, it might become a very sporadic and difficult to debug issue
13:48:44 <poornimag> yes, agreed,
13:48:50 <ndevos> so, in glfs-master.c:notify(), use the glfs->mutex and also broadcast the release through glfs->cond
13:49:29 <poornimag> yes, the broadcast is done by glfs_init_done(), so need not add it explicitly again
13:49:37 <ndevos> ah, ok
13:49:41 <ndevos> I was thinking to hold glfs->mutex while calling graph_setup()
13:50:42 <ndevos> but I have not checked completely if that is easily possible
13:52:41 <poornimag> doesn't look straight forward, as graph_setup() calls glfs_subvol_done after unlocking glfs->mutex,
13:53:12 <ndevos> yeah...
13:54:26 <poornimag> ok, so use the variable graph->used gaurded by glfs->mutex, and broadcast glfs->cond is done by glfs_init_done, so no need to do it explicitly...,
13:56:18 <ndevos> yes, but please add a comment in notify() about that, otherwise I'll be wondering again why it is missing
13:56:29 <poornimag> two things are little odd, graph->used gaurded by glfs->mutex, and glfs->cond used to notify when glfs_init_done() and when for ntifying CHILD_DONE..
13:56:34 <poornimag> yes, agreed
13:57:01 <poornimag> s/ntifying/notifying
13:57:17 <ndevos> yes, it is a little awkward, but I think we can justify that a graph is always related to a glfs structure
13:57:29 <poornimag> ok,
13:57:38 <anoopcs> Agreed
13:59:04 <ndevos> so, that settles it?
13:59:30 * ndevos will file a bug and patch for the graph->used usage in fuse-bridge.c
14:00:06 <poornimag> yes, thank you:)
14:00:25 <anoopcs> I will make the necessary changes then
14:00:40 <ndevos> cool
14:01:07 <ndevos> anything else that we need discuss about it?
14:01:27 <ndevos> otherwise we'll end the meeting and send the log to Shyam :)
14:03:03 <anoopcs> Nothing more, I think.
14:03:31 <poornimag> that is all, thank you.., will send the log to Shyam..
14:03:33 <poornimag> :)
14:03:48 <ndevos> okay, thanks guys!
14:03:53 <ndevos> #endmeeting