Re: POSIX threads early startup C++ exceptions

["Øyvind Harboe" <oyvind dot harboe at zylin dot com>]

On 8/11/06, Jonathan Larmour <jifl@jifvik.org> wrote:
> Øyvind Harboe wrote:
> > On 8/11/06, Andrew Lunn <andrew@lunn.ch> wrote:
> >> On Fri, Aug 11, 2006 at 10:59:57AM +0200, ?yvind Harboe wrote:
> >> > This went by ignored at the time, but it is still very much relevant
> >> > for early startup handling of pthreads exceptions.
> >> >
> >> >
> >> > http://sources.redhat.com/ml/ecos-patches/2005-04/msg00007.html
> >>
> >> I don't know the POSIX code very well. So this needs to be reviewed by
> >> Nick or Jifl.
> >
> > eCosPro contains support for libstdc++ and this patch is to improve
> > support for libstdc++ using POSIX threads. Could be an awkward silence
> > here. :-)
>
> Don't feel victimised, I'm pretty lousy to everyone ;). I am very aware of
> the potential conflict of interest, which is why I (and others) avoid some
> stuff, even just in case people _perceive_ we're saying something because
> of our employer, even if it's not. But I guess here it can't be avoided, so
> I assure you I am thinking with my maintainer hat here, not eCosCentric.

I don't feel victimized. I have my C++ exceptions and they work just
fine. I just see your problem with having two masters. The bible has a
thing or two to say about having two masters :-)


> By implication from this code, you're trying to get C++ code to operate
> even before the kernel is initialised, hence the hoops with self==NULL.
> It's an invitation to problems. I'm extremely hesitant about trying to
> claim that C++ code will work at such an early stage of initialisation.

It's hard to argue against a fear about something that you believe might exist.

> HALs, and the device driver API have been written as C entirely
> intentionally and by design, not because of a dislike of C++ as the
> existence of the kernel sources prove :).

I think eCos should support exceptions at such an early stage for all
the reasons I'm using exceptions in the first place. Which is why I
wrote the code in the first place.

> Even CYG_INIT_IO is after CYG_INIT_KERNEL, so I'm not clear what
> initialisation you are trying to support. C++ exceptions in the HAL? I'd
> surely have thought not, but if not but it's HAL code, why not just build
> with -fno-exceptions.

I'm decompressing an FPGA image while programming an FPGA. There are
*many* things that can go wrong and this code is *greatly* simplified
by having exceptions.

Decompressing the FPGA must happen before CYG_INIT_IO since there is a
UART in the FPGA.


> These changes also add bloat to support something that almost no-one will
> want to do, and are at best hardware specific.

Bloat? Isn't this so little as to nearly be a matter of subjective
opinion? Doesn't POSIX threads get used in system that have a little
more oomph so percentage wise this should be miniscule?

--
Øyvind Harboe
http://www.zylin.com