Re: [GCC 3.2] dll/exe exceptions patch

[Robert Collins <rbcollins at cygwin dot com>]

On Thu, 2002-08-01 at 12:35, Danny Smith wrote:
>  
> > I'd like to provide feedback, but am short of cycles myself. Can you
> > describe what it does? I can likely tell any (obvious) collisions with
> > cygwin from that.
> > 
> > Rob
> > 
> > 
> For mingw (without a special EH dll):
> The patch uses the win32api  FindAtom/AddAtom functions to create/find a local
> ATOM for an app.
> In the atom api, the atom string is case insensitive. This is used to
> advantage.  The string is coded so that 1=uppercase, 0=lowercase.  En/decoding
> the 'binary' string to a long int, cast to a void*, allows common access to
> malloc'd array that contains the addresses of EH objects.  The main .exe adds
> the local atom (and define the eh globals in the exe address space).  Dlls 
> find the local atom.  They all use the same addresses when unwinding. So no
> problems with crossing dll/exe boundaries.
> 
> Not very well explained.  The patch itself tells the story though. 
> 
> The concept may be usefully extended to other 'shared' globals.  I'm looking at
> objc now. 
> 
> For cygwin.
> The above works for cygwin  too.  There may be a better way that avoids the
> ATOM api.

This will not interact with pthreads at all AFAIK, as pthreads leverages
the native threads. If FindAtom is threadsafe on mingw, it will be on
Cygwin. As to using a better API, we can probably write one, but why
bother? 

Lastly, wouldn't SEH be a feasible alternative (if the ReactOS work is
usable).

Rob

Attachment: signature.asc
Description: This is a digitally signed message part