Re: Registries

> Me too:  all the evidence points to Tru64 behaving perfectly well
> right now.

Do you need the -tlocal behavior (notice the difference in the output)?
Ralf
From nobody Sat Jul 19 11:06:27 2003
Return-Path: <[email protected]>
Received: by stlport.com (CommuniGate Pro PIPE 3.5.9)
  with PIPE id 285593; Fri, 18 Jul 2003 05:15:11 -0700
Received: from [66.35.250.206] (HELO sc8-sf-list2.sourceforge.net)
	by stlport.com (CommuniGate Pro SMTP 3.5.9)
	with ESMTP-TLS id 285592 for [email protected];
	Fri, 18 Jul 2003 05:15:07 -0700
Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13]
	helo=sc8-sf-list1.sourceforge.net)(Debian))
	id 19dU96-0006Sw-00; Fri, 18 Jul 2003 05:15:32 -0700
Received: from a26034.upc-a.chello.nl ([62.163.26.34] helo=gerrits.homeip.net)
	(Debian))	id 19dU7j-0001Br-00
	for <[email protected]>;
	Fri, 18 Jul 2003 05:14:08 -0700
Received: from gerrits.homeip.net (unknown [192.168.1.104])
	by gerrits.homeip.net (Postfix) with ESMTP id A9AD861940
	for <[email protected]>;
	Fri, 18 Jul 2003 08:13:25 -0400 (EDT)
Message-ID: <[email protected]>
From: Dirk Gerrits <[email protected]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: langbinding <[email protected]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Boost-langbinding] at_init / at_exit proposal
Sender: [email protected]
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/boost-langbinding>,
	<mailto:[email protected]?subject=subscribe>
List-Id: <boost-langbinding.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/boost-langbinding>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=boost-langbinding>
Date: Fri, 18 Jul 2003 14:13:31 +0200
X-Spambayes-Classification: ham; 0.00
X-Mailer: CommuniGate Pro CLI mailer
Lines: 94
Xref: PENGUIN langbinding-mbox:117
X-Gnus-Newsgroup: langbinding-mbox:117   Sat Jul 19 11:06:27 2003

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 */
     }
};

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();
     }
};

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.

When embedding, this must somehow be tied to the interpreter. I'm not 
entirely sure if the Python C API provides for something like this, but 
I assume we'll have to roll our own in the boost::python::interpreter 
class (which I will gladly contribute). I guess the at_init and at_exit 
'registration facilities' will need some iostream-ish hack to avoid 
lifetime issues? Also, this has the downside that users can't safely mix 
manual use of Py_Initialize/Py_Shutdown with Boost.Python: the new 
interpreter class would be forced upon them.


If Boost.Python and luabind are to share code, I assume some of this 
will apply to luabind as well. (That's why I posted this here.) I'm not 
totally sure how this would affect the proposed mechanism though. I 
guess the at_init and at_exit callbacks would need a signature like 
function<void (lua_State*)> and they would be called at the startup or 
shutdown of every interpreter?


I'd like to hear all your comments.

just-brainstorming-ly yours,
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