Date: Tue, 13 Oct 1998 18:12:16 -0400 (EDT) From: HighWind Software Information <info@highwind.com> To: jb@cimlogic.com.au Cc: current@FreeBSD.ORG Subject: Re: Recent 3.0's are Depressing Message-ID: <199810132212.SAA07558@highwind.com> In-Reply-To: <199810132200.IAA05333@cimlogic.com.au> (message from John Birrell on Wed, 14 Oct 1998 08:00:27 %2B1000 (EST))
next in thread | previous in thread | raw e-mail | index | archive | help
The recent changes mostly affect signal handling with sigwait(). There was one change to the thread kernel, but I doubt that would be a problem. I don't see what a static link would buy you compared to a dynamic one. I also don't see what this has to do with the FreeBSD kernel since this is a user-space thread implementation. Hmm. Wouldn't statically linking OUR local libc_r into the application make it so the changes to libc_r at the customer site not effect us? Maybe I am missing something. I suggest that you use CVSup's cvs mode to track the cvs repository and then checkout sources based on date to isolate which changes have bitten you. There are test programs in the tree that were submitted by the author of the signal handling changes. You should try to duplicate your problem using those tests. Providing a ktrace without a thread status dump is useless IMO. All that you've shown is that the thread scheduler can't find a thread to run. The thread status dump should tell you why. I explained that to you many months ago. Can you review how to do that thread status dump again? I apologize for my ignorance. -Rob 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?199810132212.SAA07558>