[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] pthread_cancel and clone weirdness

cvaroqui zezette:tmp$ ./pthread_test
cancelling thread
pthread cancel returned : Success
joining thread
pthread_join returned : Success
child was canceled

both with and without "#define WORK_CORRECTLY 1" on ubuntu breezy HEAD,

Will try on Debian Sid/amd64 too, tomorrow.

That said, we may now be able to kill all the clone/prepare_namespace()

They were introduced to protect from /sbin/multipath exec failures under
memory pressure. Now, the daemon doesn't exec multipath anymore, so if
nobody cares, I'll kill them soon, and go back to pure fork()-based


On sam, 2005-07-16 at 09:31 -0500, Benjamin Marzinski wrote:
> O.k. I finally figured out why pthread_cancel just wasn't working for me,
> and it has something to do with the clone() call in multipathd. If you
> fork child(), everything works correctly. If you clone it, pthread_cancel
> dosn't work on PTHREAD_CANCEL_ASYNCHRONOUS type threads. This makes
> no sense to me.  Is this supposed to happen??
> Could people please try running the attached test program? When I use
> clone() (WORKS_CORRECTLY set to 0) it hangs. When I use fork()
> (WORKS_CORRECTLY set to 1) it does exactly what I expect.  This is happening
> for me on RHEL4. I would be interested in knowing if it happens on other
> distros.
> Thanks
> -Ben
> --
> dm-devel mailing list
> dm-devel redhat com
> https://www.redhat.com/mailman/listinfo/dm-devel
christophe varoqui <christophe varoqui free fr>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]