From owner-freebsd-current Tue Oct 20 19:42:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA05754 for freebsd-current-outgoing; Tue, 20 Oct 1998 19:42:50 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from highwind.com (hurricane.highwind.com [209.61.45.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05749 for ; Tue, 20 Oct 1998 19:42:48 -0700 (PDT) (envelope-from info@highwind.com) Received: (from info@localhost) by highwind.com (8.8.6/8.8.6) id WAA00469; Tue, 20 Oct 1998 22:41:12 -0400 (EDT) Date: Tue, 20 Oct 1998 22:41:12 -0400 (EDT) Message-Id: <199810210241.WAA00469@highwind.com> From: HighWind Software Information To: eischen@vigrid.com CC: dima@tejblum.dnttm.rssi.ru, eischen@vigrid.com, current@FreeBSD.ORG, lists@tar.com, tejblum@arc.hq.cti.ru In-reply-to: <199810210200.WAA04708@pcnet1.pcnet.com> (message from Daniel Eischen on Tue, 20 Oct 1998 22:00:30 -0400 (EDT)) Subject: Re: Another Serious libc_r problem Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes, it seems that we need a method of disabling task scheduing while we enqueue the condition variable and call the thread kern scheduler. You should be able to do this by setting _thread_kern_in_sched = 1. Something like this (from pthread_cond_timedwait): Hmmm. If this is necessary here, wouldn't it be needed in other places in libc_r. Like uthread_mutex.c, uthread_join.c, uthread_fd.c Perhaps I'm confused. -- In the meantime, the earlier patch to uthread_cond.c seems to have worked. However, I'd really like to see libc_r become even more robust. I think it is time someone with commit-priv's gets involved to integrate this good work. We are happy to keep beating up the library and providing test programs that make it unhappy. -Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message