[C++-sig] [patch] Make boost python accessible by multiplethreads

[Matthew Scouten (TT)]

I agree that automatic GIL Management should not go main line unless it is done right. 

I would like some facilities for manual GIL management though.

I have a RAII object for taking the GIL around a virtual function, and another for freeing the GIL around a call in. Something like that would be nice to put in the library. I can donate mine if asked...  

-----Original Message-----
From: cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org [mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org] On Behalf Of Niall Douglas
Sent: Saturday, July 17, 2010 9:18 AM
To: Development of Python/C++ integration
Subject: Re: [C++-sig] [patch] Make boost python accessible by multiplethreads

On 16 Jul 2010 at 12:33, Jim Bosch wrote:

> But I don't know much more than this, and I'm also curious to hear the 
> story told by someone who has more information...why hasn't 
> multithreading support been added?  Does it just add too much overhead 
> for those who don't need it?

Atomic exchange instructions are a very precious commodity on modern 
systems and become ever more precious over time. Wherever possible 
atomic exchange instructions ought to be avoided for the benefit of 
the whole system.

Besides, one of the big problems with a "naive" threading support 
implementation such as the one just posted is that there are loads of 
occasions (e.g. when checking for an overload of a virtual function) 
when you unlock, do less than 100 cycles of work which doesn't need 
the unlock and relock. That's crazy, and it hammers performance 
across your entire system.

What was discussed on here many months ago was a simple "hanging 
lock" system which avoids the problem above. It will however also 
require source code changes to code using Boost.Python, but wrapper 
generators like Py++ would take most of the pain.

The problem, as always, is funding the time of those to implement a 
proper solution which would pass muster under peer review. The naïve 
implementation is not suitable for mainline, and I agree it should be 
kept out until it's done properly. Annoyingly you could probably get 
a full and proper implementation for just ~US$7-8k as it's a feature 
most Boost developers would feel very favourably toward.

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.



_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig