Camelia, the Perl 6 bug

IRC log for #gluster-dev, 2013-07-01

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:18 bulde joined #gluster-dev
02:41 bharata joined #gluster-dev
03:06 shubhendu joined #gluster-dev
04:50 hagarth joined #gluster-dev
05:05 kshlm joined #gluster-dev
05:06 bulde joined #gluster-dev
05:15 mohankumar__ joined #gluster-dev
06:09 raghu joined #gluster-dev
06:22 vshankar joined #gluster-dev
06:26 kshlm joined #gluster-dev
06:39 bala joined #gluster-dev
06:53 puebele joined #gluster-dev
07:11 puebele joined #gluster-dev
10:22 bala joined #gluster-dev
10:47 hagarth joined #gluster-dev
12:01 bfoster joined #gluster-dev
12:08 edward1 joined #gluster-dev
12:13 rgustafs joined #gluster-dev
12:57 bala joined #gluster-dev
13:10 blues-man joined #gluster-dev
13:33 mohankumar__ joined #gluster-dev
13:53 hagarth joined #gluster-dev
14:07 deepakcs joined #gluster-dev
14:07 wushudoin joined #gluster-dev
15:23 Technicool joined #gluster-dev
15:31 jclift_ joined #gluster-dev
15:45 xavih ndevos: ping
15:45 ndevos hey xavih
15:46 xavih ndevos: hi
15:46 ndevos xavih: looking at my patch again?
15:47 xavih ndevos: Yes, I'm sorry... :/
15:47 ndevos xavih: no problem, lets (try to) get some quality code ;)
15:48 xavih ndevos: I'm not sure at what level I should accept it. There are possible races, thought very improbable...
15:48 jclift_ races... ugh
15:48 xavih yes, imagine you initialize interval to 30
15:49 * ndevos imagines
15:49 xavih then everything is checked and the thread created, but not started yet
15:49 ndevos jclift_: http://review.gluster.org/5176 btw
15:49 ndevos xavih: yes
15:49 xavih the locked block of code ends and immediately interval is reconfigured to 0
15:50 jclift_ Meh, C code.
15:50 xavih then the thread starts reads interval as 0 and terminated the thread
15:50 * jclift_ is not trying to re-familiarise with C any time soon
15:50 ndevos xavih: yes, still following, until now it is intended
15:51 xavih then posix_spawn_health_check_thread() is executed to handle the reconfiguration
15:51 xavih and it tries to cancel a finished and released thread...
15:51 xavih probably a crash
15:52 xavih btw, it is not needed to LOCK()/UNLOCK() to read the health_check_interval. Normal reads are already atomic
15:52 ndevos xavih: you think posix_thread_cancel() would crash if the thread does not exist anymore?
15:53 ndevos ah, I was wondering about that, maybe some architecture does not have a atomic uint32_t... well, unlikely maybe
15:54 xavih well, the man page is not very explicit in this point
15:55 xavih it assumes that the thread is created in attached state and an explicit pthread_join() is made (at this point the resources are released)
15:55 xavih however if the thread is detached, the resources are automatically released
15:56 xavih and it is not clear if pthread_cancel() can be called safely
15:56 xavih some web browsing makes me believe that it may crash, at least in some implementations
15:57 ndevos xavih: my understanding is that pthread_cancel() may not crash on an invalid thread-id, it may return EINVAL or ESRCH (or something like that iirc)
16:02 xavih ndevos: form POSIX.1-2008: The lifetime of a thread ID ends after the thread terminates if it was created with the detachstate attribute set to PTHREAD_CREATE_DETACHED or if pthread_detach() or pthread_join() has been called for that thread. A conforming implementation is free to reuse a thread ID after its lifetime has ended. If an application attempts to use a thread ID whose lifetime has ended, the behavior is undefined
16:04 ndevos xavih: hmm, indeed
16:05 xavih this means that the id of the finished thread could be reused after termination but before cancellation, making that pthread_cancel() kills an unintended thread
16:05 ndevos yeah, that looks possibe
16:05 ndevos *possible
16:05 xavih very improbable, but...
16:08 xavih ndevos: I think a simple way to solve the problem would be to not directly modify health_check_interval but read it in a temporary variable and modify it inside the locked section
16:08 xavih ndevos: the pass this variable to the thread, instead of making the thread read it from priv structure
16:09 xavih anyway the thread will be stopped every time this value is changed
16:09 ndevos xavih: hmm, I actually thought about that earlier on, not sure why I did not persuade that...
16:10 ndevos xavih: could you leave that as a note in the review? I have to leave now...
16:10 xavih ok, no problem :)
16:10 ndevos thanks!
16:10 xavih yw
16:29 bulde joined #gluster-dev
17:05 bala joined #gluster-dev
17:32 lpabon joined #gluster-dev
18:15 sghosh joined #gluster-dev
21:08 foster joined #gluster-dev
21:26 badone joined #gluster-dev
21:33 badone joined #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary