Re: at_init / at_exit proposal

David Abrahams wrote:

> Hi Dirk,

Hi. :)

> Dirk Gerrits <[email protected]> writes:
> 
> 
>>Boost.Python currently uses some global/static variables that cause
>>problems in embedding. (Basically you can't call Python's cleanup
>>routines because the variables would be cleaned up after Python
>>itself, causing a crash.)
>>
>>I propose to add a mechanism like the following which I hope will help
>>to fix this issue:
>>
>>struct at_init
>>{
>>     explicit at_init(function<void ()> f)
>>     {
>>         if (extending)
>>             f();
>>         else
>>             /* register f somewhere to be called after
>>             the interpreter starts */
>>     }
>>};
> 
> 
> I can't imagine what we'd want this for.  Module import time is early
> enough to initialize any state associated with a module, and the rest
> of the state can safely live forever.

Oh okay. Can it even safely live on when the (embedded) Python 
interpreter is not running anymore? And will it still work when the 
Python interpreter is then later restarted?

>>struct at_exit
>>{
>>     function<void ()> m_f;
>>
>>     explicit at_exit(function<void ()> f)
>>         : m_f(f)
>>     {
>>         if (embedding)
>>             /* register f somewhere to be called before the
>>             interpreter shuts down */
>>     }
>>
>>     ~at_exit()
>>     {
>>         if (extending)
>>             m_f();
>>     }
>>};
> 
> 
> I don't understand the logic here.  Why would we want different
> behavior for extending and embedding?

If we 'roll our own', we'd have to. But I guess Python's atexit module 
would serve both needs. Now, why didn't I think of that before? :P

>>Example usage:
>>namespace {
>>
>>registry_t* registry;
>>void create() { registry = new registry_t;
>>                 /* initialization */ }
>>void destroy() { delete registry; }
>>at_init registry_creation(&create);
>>at_exit registry_destruction(&destroy);
>>
>>registry_t& entries() { return *registry; }
>>..
>>} // unnamed
>>
>>This will allow things to be done at interpreter startup and shutdown,
>>like the conversion registry initialization and shutdown above.
>>
>>When extending, this is the same as the 'startup' and 'shutdown' of
>>the translation unit.
> 
> 
> I don't think we need to tear down the entire registry at shutdown.
> It seems enough to reset all of the object()s and handle<>s it's
> holding.

Sounds reasonable.

Dirk Gerrits



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Boost-langbinding mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
From nobody Sat Jul 19 11:06:28 2003
Return-Path: <[email protected]>
Received: from smtp01.mrf.mail.rcn.net ([207.172.4.60] verified)
  by stlport.com (CommuniGate Pro SMTP 3.5.9)
  with ESMTP id 286384 for [email protected]; Sat, 19 Jul 2003 04:33:33 -0700
Received: from 146-115-123-42.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com ([146.115.123.42] helo=PENGUIN.boost-consulting.com)
	by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.35 #4)
	id 19dpy7-0004m7-00; Sat, 19 Jul 2003 07:33:39 -0400
To: [email protected]
Subject: Re: [Boost-langbinding] at_init / at_exit proposal
References: <[email protected]>
	<[email protected]> <[email protected]>
From: David Abrahams <[email protected]>
Date: Sat, 19 Jul 2003 07:33:13 -0400
In-Reply-To: <[email protected]> (Dirk Gerrits's message
 of "Sat, 19 Jul 2003 02:53:52 +0200")
Message-ID: <[email protected]>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 19
Xref: PENGUIN langbinding-mbox:120
X-Gnus-Newsgroup: langbinding-mbox:120   Sat Jul 19 11:06:28 2003

Dirk Gerrits <[email protected]> writes:

> David Abrahams wrote:

>>Module import time is early
>> enough to initialize any state associated with a module, and the rest
>> of the state can safely live forever.
>
> Oh okay. Can it even safely live on when the (embedded) Python
> interpreter is not running anymore? And will it still work when the
> Python interpreter is then later restarted?

It can certainly be designed that way.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com