[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mapping thread_t <-> cthread_t
From: |
Marcus Brinkmann |
Subject: |
Re: mapping thread_t <-> cthread_t |
Date: |
Thu, 7 Feb 2002 03:10:24 +0100 |
User-agent: |
Mutt/1.3.27i |
On Wed, Feb 06, 2002 at 08:12:57PM -0500, Roland McGrath wrote:
> Once it's detached, you can't presume the cthread_t is still good (since it
> might die at any time). So the only safe thing is if you have some data
> structure that tells you for sure that the thread is live and blocked
> somewhere because the thread itself wrote the data structure and then
> blocked. In short, yes.
Thanks. For pthreads, this will have to be reworked a bit, so I just set a
global as early as possible (but within the global lock). As those threads
run in a loop and thus are always blocking if they happen to hold the global
lock, it doesn't make sense for them to touch the variable to indicate their
status.
I have now tested my code, there are some glitches, but it already works to
some extent. I started testing with a normal file, but echoing and the
limited size of the input buffer (which leads to echoed bells!) made this
unworkable. Stacking term translators also works (bugs everywhere, but
nothing that gdb can't manage).
By the way, I wonder if the comparatively small input buffer size of 256 bytes
that term is using might be a reason for the problems with ppp over a serial
line. I will have to try increasing the size and seeing if higher speeds works.
(Certainly GNU Mach will have its own limit, but I still wonder if 4800 baud
is really GNU Machs limit on a fast computer like mine).
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de