Date: Wed, 21 Oct 1998 01:33:14 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: eischen@vigrid.com, info@highwind.com Cc: current@FreeBSD.ORG, dima@tejblum.dnttm.rssi.ru, lists@tar.com, tejblum@arc.hq.cti.ru Subject: Re: Another Serious libc_r problem Message-ID: <199810210533.BAA20955@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> 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 Yeah, probably. It is a very, very small window where the timer can go off and schedule a new thread, but it could still happen. > Perhaps I'm confused. Nope :-) > 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. Eivind Eklund said in previous mail that he was working on mutexes. Maybe if you send him a T-shirt, he'll do it for you :-) Dan Eischen eischen@vigrid.com 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?199810210533.BAA20955>