Path: csiph.com!usenet.pasdenom.info!news.albasani.net!news.stack.nl!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <54cd96b5$0$12994$c3e8da3$5496439d@news.astraweb.com>
References: <0b8db0f6-75c5-4a8f-a9a5-51fa936b306e@googlegroups.com> <8ff4c8aa-a858-481f-8964-7c794f848de2@googlegroups.com> <mailman.18322.1422653315.18130.python-list@python.org> <54cd96b5$0$12994$c3e8da3$5496439d@news.astraweb.com>
Date: Sun, 1 Feb 2015 14:21:22 +1100
Subject: Re: RAII vs gc (was fortran lib which provide python like data type)
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.18346.1422760885.18130.python-list@python.org>
Lines: 75
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:84976

On Sun, Feb 1, 2015 at 2:00 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> A C++ statement with RAII like
>>
>> {
>>    Foo bar();
>>    // suite
>> }
>>
>> is not equivalent to
>>
>>     bar = Foo()
>>
>> in Python. It actually corresponds to
>>
>> with Foo() as bar:
>>     <suite>
>
>
> Nice answer! I'm not qualified to tell whether you are right or not, but
> what you say has the ring of truth about it.

I would say that this is indeed correct, with the caveat that RAII is
most often used for memory allocation, in which case the correct
transformation into Python _would_ be a constructor call. But when you
use this kind of thing to set up state and clean up afterwards, then
yes, Python's equivalent would be a context manager.

So a C++ way to release and reacquire the GIL might look like this
(borrowing from https://docs.python.org/3.5/c-api/init.html):

class ReleaseGIL
{
    //Internal state
    PyThreadState *_save;
public:
    //Constructor
    ReleaseGIL() {_save = PyEval_SaveThread();}
    //Destructor
    ~ReleaseGIL() {PyEval_RestoreThread(_save);}
};

//Usage example:
int do_work()
{
    while (1)
    {
        //use the Python C API to figure out what we need to do
        ReleaseGIL heavy_processing_coming;
        //do the heavy computational work
    } //GIL is reacquired here
}


The Python equivalent would be something like:

@contextlib.contextmanager
def release_gil():
    """Why the <bleep> are we manipulating the
    GIL from Python code anyway???"""
    _save = PyEval_SaveThread()
    yield
    PyEval_RestoreThread(_save)

def do_work()
    while True:
        # get some work
        with release_gil() as heavy_processing_coming:
            # do the heavy computational work
        # GIL is reacquired here

In each case, you have a guarantee that code following the suite will
not be executed without first performing the appropriate cleanup.

ChrisA