[K42-discussion] Cause of cxa_atexit/dso_handle reference

[Bryan S Rosenburg]

I'm sorry for not being more responsive.  As Orran said, we're really busy 
working toward an internal milestone for the next few weeks.

I'm still in favor of avoiding global objects on general principles, but 
not if it involves solving too many case-by-case problems.  I think the 
particular DeletedObject case can be solved with a dynamic allocation 
using the "primitive" memory allocator.  I've attached a patch below.  The 
patch compiles, but I haven't tested it, and I certainly haven't verified 
that it avoids the cxa_atexit requirement.

If there are too many cases, or if there are cases that can't be easily 
resolved, I'd fall back on providing a cxa_atexit() that doesn't do 
anything.  There's really no point in recording the cleanup functions when 
there's no code that will ever call them.

Here's the patch for dynamically allocating theDeletedObj: 

- Bryan

Patrick Bridges wrote on 08/16/2006 02:17:32 PM:
> 
> On Aug 15, 2006, at 3:25 PM, Bryan S Rosenburg wrote:
> 
> >
> >
> > Patrick Bridges wrote on 08/15/2006 05:14:02 PM:
> > > So, should we just break down and put together simple implemetations
> > > of cxa_atexit and dso_handle, or should we further limit the 
> > kinds of
> > > things we do in C++ to avoid these problems (i.e., either forbid
> > > destructors in certain classes or forbid global objects of certain
> > > types)?
> >
> > I'm in favor of forbidding global objects of certain types, if we 
> > can make that work.  We've tried to avoid global objects in 
> > general, and the closer we can keep to that standard, the better.
> >
> > Patrick, thanks for looking into this issue so thoroughly.
> 
> My feeling would be to go ahead and support cxa_atexit and global 
> objects since, unlike exceptions and rtti for example, it should be 
> relatively straightforward. It'll also make porting easier since we 
> won't have to continually hack around these problems on a case-by- 
> case basis.
> 
> If we don't want to, any suggestion on how to fix this particular 
> case? Can we simply allocate "theDeletedObject" at runtime by new(), 
> or if not new, by casting a static buffer to the appropriate type? I 
> guess part of my problem is that I don't yet understand exactly how 
> it's used and integrates with the fslib stuff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20060823/3ce58278/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dynDelObj.patch
Type: application/octet-stream
Size: 3152 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/k42-discussion/attachments/20060823/3ce58278/attachment.obj