Date: Tue, 11 Dec 2001 18:12:37 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Bill Huey <billh@gnuppy.monkey.org> Cc: Nate Williams <nate@yogotech.com>, absinthe@pobox.com, shanon loveridge <shanon_loveridge@yahoo.co.uk>, freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <Pine.SUN.3.91.1011211180304.28589A-100000@pcnet1.pcnet.com> In-Reply-To: <20011211223318.GB2002@gnuppy>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Dec 2001, Bill Huey wrote: > On Tue, Dec 11, 2001 at 08:18:47AM -0500, Daniel Eischen wrote: > > Yes, it is ;-). Please don't let anything like this get committed > > without giving me a chance to deuglify it :-) :-) > > Oh, no, it's definitely not ready for CVS commit. It's definitely pure > super-slop, but I needed to at least get it out so that folks that are > responsible for the pthreads system can look at the logic and possibly > reimplement it in the style and manner it's expected to be. > > Uh, > > 1) The timespec stuff seems ok since it cleans up the useage of it and > treats it properly a vector with associated add/substract > operations instead of just inserting random logic at those > points. The might be a good style > change for that part of the library. I think there are already macros to handle timespec add and subtract, but they are not visible outside of the kernel (hidden behind #ifdef _KERNEL). > 2) The state_log stuff was essential for me to track down the bug in the > first place and it's up to you whether you'd like to keep it in > or not. It's sloppily pieced together at this point and I'm not > in a place where I really care about that as much as just trying > to get it and the JVM to work correctly in the first place. I'd rather get rid of it. > 3) The waiting queue recalculation stuff seems to be logically ok, but > was also sloppily glued together. I only marginally care for the > same reason as above. ;-) Not sure why this is needed. In general, wait times are in absolute times and blocking conditions internal to the threads library should be able to handle errant wakeups (so they don't return to the caller). This is essential for signal handling to work properly. If a thread waiting on a mutex or condition variable has to handle a signal, it needs to dequeue itself from the mutex/cv queue, run the signal handler, and then it returns to the mutex or cv routine (which detects the errant wakeup, requeues the thread, and calls the scheduler to block and schedule another thread again). > In summary, I'm basically lazy and would like you to fix all the > problems with it. ;-) That didn't look like a patch to -current libc_r; was it? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1011211180304.28589A-100000>