Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Aug 2010 13:32:39 +0000
From:      David Xu <davidxu@freebsd.org>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        freebsd-threads@freebsd.org
Subject:   Re: PTHREAD_CANCEL_DEFERRED
Message-ID:  <4C6BE0F7.10207@freebsd.org>
In-Reply-To: <4C6AA092.40708@freebsd.org>
References:  <4C642E9B.8000300@freebsd.org>	<20100812093353.GS2396@deviant.kiev.zoral.com.ua>	<4C650D0F.9060905@freebsd.org> <4C650F27.1000305@freebsd.org>	<20100813141402.GW2396@deviant.kiev.zoral.com.ua>	<4C65E0FE.2030803@freebsd.org>	<20100814144715.GB2396@deviant.kiev.zoral.com.ua>	<4C6926D0.2020909@freebsd.org>	<20100816082022.GO2396@deviant.kiev.zoral.com.ua>	<4C696A96.7020709@freebsd.org>	<20100816104303.GP2396@deviant.kiev.zoral.com.ua> <4C6AA092.40708@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote:
> My idea is to always let close() syscall run, until it will be
> blocked by lower layer, e.g tty or socket layer, as manual of close()
> said it always release the file descriptor despite whether
> it returns EINTR or EWOULDBLOCK, when it is going to sleep,
> a flag will cause it to abort the sleep.
> if the thread does not found the flag at that time,
> a latter signal SIGCANCEL sent by pthread_cancel will unblock it,
> this is how signal works.
>

I have worked out a patch:
http://people.freebsd.org/~davidxu/patch/thread_cancel.patch





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C6BE0F7.10207>