[pypy-dev] pypy blocked at RPyGilAcquire ()

[Maciej Fijalkowski]

so far you can't do it (initialize pypy twice), we can maybe think
about supporting it (and e.g. have interpreter instances) but it's
quite some work. Generally speaking, we don't guarantee you any
isolation (but you're free to execute stuff in your own namespace
anyway,. but stuff like sys.modules etc. won't be cleaned for you)

On Thu, Jun 25, 2015 at 12:34 PM, Yicong Huang <hengha.mao at gmail.com> wrote:
> Hi,
>
> We embedded Pypy in C++ code, and found out if Pypy was initialized twice it
> would block at function RpyGilAcquire().
> Here is the  case:
>
> rpython_startup_code();
> res = pypy_setup_home("...")
> res = pypy_execute_source_ptr(...)
> //Some code here
> rpython_startup_code();
> res = pypy_setup_home("...")
> res = pypy_execute_source_ptr(...)
>
> We found pypy blocked at second pypy_execute_source_pty(...), the detail
> call stack are
> #0  0x0000003fea40b1c0 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1  0x00007f8543087a1d in RPyGilAcquire () from
> /usr/ali/odps-pypy/libpypy-c.so
> #2  0x00007f85425a5f8d in pypy_g_pypy_execute_source_ptr () from
> /usr/ali/odps-pypy/libpypy-c.so
> #3  0x00007f85423a6743 in pypy_execute_source_ptr () from
> /usr/ali/odps-pypy/libpypy-c.so
>
> The reason that we initialized pypy twice is that we would like to get a
> clean environment to execute without any global variables' pollution from
> the first run.
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>