Re: [pygccxml-development] Feature request: Creating thread safe methods

[Roman Y. <rom...@gm...>]

On 7/31/06, Matthias Baas <ba...@ir...> wrote:
> This is a good idea for the case when the entire function/method has to
> be surrounded by the above calls.
>
> virtual void foo(){
>    PyGILState_STATE gstate;
>    gstate = PyGILState_Ensure();
>
>    bp::override func_foo = this->get_override( "foo" );
>    if( func_foo )
>    {
>       func_foo( );
>       // at this point the user might want to add code that
>       // checks for exceptions (or does the above function
>       // call already raise a C++ exception? then there
>       // should be a try...catch block)
>    }
>
>    PyGILState_Release(gstate);
>
>    if (!func_foo)
>       Foo::foo( );
> }

virtual void foo(){
   {
        gilguard guard;
        if( bp::override func_foo = this->get_override( "foo" ) )
            func_foo( );
        return;
   }
    Foo::foo( );
}

The point is that you still can use the guard. Another point, is that
we are talking
here about optimization. Lets just skip it.

> >> However, this code is generated by pyplusplus and currently I don't see
> >> a way to inject the extra code.
> >
> > Now can you see the problem with virtual functions and arguments policies?
> > They don't work well together :-(. The main problem is that function
> > signature is changed.
>
> Well, yes, but in this case we are actually dealing with two wrapper
> methods, aren't we? One for the case when the call is made from C++ and
> one for the case when the call is made from Python.
> So far, my existing arg policies are dealing with the case when the call
> is made from Python and goes down to C++. Hm, maybe the other direction
> just needs a separate set of "arg policy" classes....?

There are reasons I did not start to implement this functionality. I
don't know the
answer. It is clear to me that user will have to choose between X and Y.
But it is not clear to me what X and Y are.

It will be perfectly good to make an assumption, that most of the time users
don't embed Python within C++, but rather extend Python. We can start to discuss
a solution that will be based on this assumption.

> So far, the virtual methods in the Maya SDK are always called from C++,
> so I would only need one direction. But I have only considered a few
> classes and methods yet, there might still be methods where the derived
> class wants to invoke the inherited method...

I think, we will have to build some use cases table and for every use case to
write an expected solution.

> >> Then there's another issue related to thread-safety. Locking the Python
> >> interpreter is one thing, but you also have to catch any exception that
> >> is raised in the Python code and take some appropriate actions (like
> >> reporting the exception and, in my case, returning an appropriate error
> >> status code to Maya).
> >
> > Will exception neutral code will solve this problem?
>
> What do you mean by this?

If we will generate an exception neutral code, then we move the responsibility
to treat exception to boost.python and to the user. The only exception to this
case is when you have to translate exception to some kind of return code.

> If you mean that the actual policy class is outside py++ (but of course,
> the framework for this to work is inside py++), then I agree.... :)

I think we understand each other.  I meant, that you will define what
services you will need from py++ in order to implement this feature
efficiently. Also do you
mean "actual policy class" is something similar to classes that derives from
ArgTransformerBase?

By the way, do you want to rename it? Thread safety has nothing to do with
arguments.

> > Every overridable virtual member function looks like:
> >
> > 0 virtual int pure_virtual( int x ){
> > 1
> > 2    bp::override func_pure_virtual = this->get_override( "pure_virtual" );
> > 3
> > 4 return func_pure_virtual( x );
> > 5
> > 6 }
> >
> > It seems, that user needs to add code to 1, 3, 5 and to be able to
> > modify 2,4. Am I right?
>
> In principle, yes. Of course, as I wasn't dealing with virtual methods
> yet I have no distinction between 1 and 3 (as line 2 doesn't appear in
> the code generated by the existing arg policy mechanism), so both of
> them would be "pre-call" whereas 5 is "post-call".

>Additionally, there
> should be a way to allocate local variables (this has to be done via an
> API call so that the variable name can be adjusted if necessary to
> prevent name clashes).

I am  not sure about this, really. We should see.

Matthias, can you write some document that will contain description of
what you are going to do:
1. use case
2. proposed solution
3. user interface/API
4. pyplusplus API

Something like this. I think it will cause us to work together and
better understand
the problem and solution.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/