Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Jan 2003 21:57:34 -0500
From:      David Rhodus <david@uky.edu>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        Juli Mallett <jmallett@FreeBSD.org>, current@FreeBSD.org
Subject:   Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
Message-ID:  <7076C6DC-2059-11D7-94F8-00039380DD2C@uky.edu>
In-Reply-To: <Pine.NEB.3.96L.1030104175853.82416D-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Saturday, January 4, 2003, at 06:00 PM, Robert Watson wrote:

>
> On Sat, 4 Jan 2003, Juli Mallett wrote:
>
>> * De: Robert Watson <rwatson@FreeBSD.org> [ Data: 2003-01-04 ]
>> 	[ Subjecte: pthread ^T problem on recent -CURRENT: death in libc_r 
>> mutex ]
>>>
>>> Juli Mallett pointed me at the following reproduceable problem on my
>>> -current notebook with userland/kernel dated Dec 29:
>>
>> Incidentally, this doesn't illustrate the problem I was actually 
>> trying
>> to point out.  Try making the sleep's pthread_yield().  That will make
>> the threads never run again.  sleep is the hack I've had to do.  In my
>> appp, I have a 'my_yield' function which will sleep on FreeBSD, and
>> yield on everywhere else :(
>
> Hmm.  I'm not experiencing that problem -- if I replace the sleep() 
> with
> pthread_yield(), I get a long sequence of '1's until thread2 is 
> started,
> and then clean alternation between '1' and '2'.  I don't see any 
> failure
> to schedule a thread after it has yielded.
>
> I'm updating my box from Dec 29 to today to see if that makes a 
> difference
> either way on either problem.
>
With pthread_yield() I get the same as Watson. It still core's with a 
few ctrl-T's.
I'm running today's source.

-DR


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7076C6DC-2059-11D7-94F8-00039380DD2C>