Document about threads
Hey all, I have been trying to port some code to FreeBSD which currently runs under Linux (and to some degree, Solaris). Since I'm a longtime FreeBSD user, I'm pretty excited to get a chance to port to FreeBSD. The program I'm working on uses both POSIX threads and ISO C++ (including templates, exceptions, etc.), so I needed information about the current state of such things under FreeBSD. However, there wasn't any "one-stop" documentation I could find about the current state of everything. As a result, I ended up writing a brief text document which describes what I found out about threads (C++ and threads is only mentioned briefly). If anyone who knows about the state of the FreeBSD threads implementation could go through it and check it for factual errors, missing bits, etc. then that would be great. Included at the end of the document is a little bit about the planned implementation using scheduler activations for -CURRENT, but that section is almost totally just posts copied from the mailing list archives. I would be happy to contribute this information to the Documentation project if that would be preferable. The URL for the document is http://www.idiom.com/~bko/bsd/freebsd-threads.txt A few quick questions: 1. I had seen an email in the mailing list archives which asserted that C++ exceptions have been broken since August 1999 in the multithread case -- does anyone know what the status in 4.1-STABLE and -CURRENT are? I've managed to get the code to compile under FreeBSD, but it crashes quite rapidly after this, and I'm wondering if it's because of an exception being thrown. This is under 4.1-RELEASE. 2. Sometimes, the programs crash at startup, but not always. I seem to recall a recent discussion about the loader not being multi-thread safe -- was this fixed in time for 4.1-RELEASE ? Thanks, -- bryan k ogawa <[EMAIL PROTECTED]> http://www.primenet.com/~bkogawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Document about threads
hi, there! On Fri, 25 Aug 2000, Bryan K. Ogawa wrote: > 1. I had seen an email in the mailing list archives which asserted that > C++ exceptions have been broken since August 1999 in the multithread case > -- does anyone know what the status in 4.1-STABLE and -CURRENT are? I've > managed to get the code to compile under FreeBSD, but it crashes quite > rapidly after this, and I'm wondering if it's because of an exception > being thrown. This is under 4.1-RELEASE. this issue is unrelated to threads. FreeBSD stock g++ 2.95.2 compiler uses -fsjlj-exceptions mechanism for exception handling which is broken (g++ sometimes generates incorrect code even without any optimization options given). It is not FreeBSD-specific behaviour. gcc GNATS has bug report with similar gcc behaviour under OS/390. uou can still use /usr/ports/lang/egcs -- this is the same 2.95.2 but it uses DWARF2 unwinding info for exception handling -- the same mechanism that is used by default under Linux and (IIRC) Solaris. I believe that FreeBSD g++ will switch to this scheme in near future. I have initial set of patches that adds support to FreeBSD CRT startups for loading info from .eh_frame ELF sections needed for DWARF2 unwinding info mechanism to work. David O'Brien has all the information. I think he can shed some light on this issue (he is gcc/binutils maintainer) but he seems to be busy with other tasks -- I still haven't got any replies from him except "go ahead, it would be nice to have this feature" :) > 2. Sometimes, the programs crash at startup, but not always. I seem to > recall a recent discussion about the loader not being multi-thread safe -- > was this fixed in time for 4.1-RELEASE ? yes, I beleive /fjoe PS you will also have problems with shared libraries debugging (see PR/20373). I have solution for this problem too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Document about threads
> this issue is unrelated to threads. FreeBSD stock g++ 2.95.2 compiler > uses -fsjlj-exceptions mechanism for exception handling which is broken > (g++ sometimes generates incorrect code even without any optimization > options given). It is not FreeBSD-specific behaviour. gcc GNATS has > bug report with similar gcc behaviour under OS/390. There was a bug in -fsjlj-exceptions code generation related to shared libraries and to best of my knowledge the correct fix has been imported into the official gcc CVS tree and was merged into FreeBSD some time ago. Are there any other errors you know about? If there are any simple code snippets which can demonstrate the problem, I am willing to investigate it further and see if it can be fixed. -fsjls-exceptions errors should be fixed regardless of whether FreeBSD is going to switch to DWARF scheme or not. 4.x-STABLE is here to stay for quite some time and I doubt that it will ever be changed to use DWARF unwinding. -- E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]> Date: 25-Aug-00 Time: 09:45:59 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Document about threads
>From: "Bryan K. Ogawa" <[EMAIL PROTECTED]>
>
>If anyone who knows about the state of the FreeBSD threads implementation
>could go through it and check it for factual errors, missing bits, etc.
>then that would be great.
in your section about common reentrant extensions, you mention the IPv6
apis. these are currently _not_ a viable alternative to the missing
traditional gethostby{name,addr}_r entrypoints due to a bug in KAME. they
are not threadsafe. your process will deadlock if multiple threads call
getipnodeby{addr,name}. see http://orange.kame.net/dev/query-pr.cgi?pr=277.
--
-greg
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Document about threads
hi, there!
On Fri, 25 Aug 2000, Alexander N. Kabaev wrote:
> There was a bug in -fsjlj-exceptions code generation related to shared
> libraries and to best of my knowledge the correct fix has been imported into
> the official gcc CVS tree and was merged into FreeBSD some time ago. Are there
> any other errors you know about? If there are any simple code snippets which can
> demonstrate the problem, I am willing to investigate it further and see if
> it can be fixed. -fsjls-exceptions errors should be fixed regardless of whether
> FreeBSD is going to switch to DWARF scheme or not. 4.x-STABLE is here to stay
> for quite some time and I doubt that it will ever be changed to use DWARF
> unwinding.
this is definitely not the case with shared libraries -- I know about that
bug and the fix was merged to FreeBSD CVS source tree somewhere around
beginning of this year. unfortunately I have no simple code snippets and
have no time to investigate it further. but I have an application that
demonstrates this bug: Reactor_Exceptions_Test from ACE wrappers
(you can get ACE wrappers from http://www.cs.wustl.edu/~schmidt/).
the test itself is quite simple snippet but you will need to build ACE to
run it. please look at #413 and #258 in gcc GNATS.
all that I found is that emitted setjmp got optimized during flow analysis
stage in such way that when exception is raised execution continues
in try { } block (yes, again) instead of place where decision is taken in
which catch { } block the execution should be continued.
I do not know about any other 2.95.2 bugs.
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
