bug-hurd
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]