pypy blocked at RPyGilAcquire ()
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.
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@gmail.com> wrote:
Ran into a similar concept concern while doing some proof of concept work for my company. The approach that looked the most promising/easiest for a clean pypy state (both rpython internal and python globals) was to embed the sandbox controller and have it call out/create a new sandbox for each unit of isolated code. Although if you control the python code, reworking it such that it does not share global state is perhaps the best idea. On Thu, Jun 25, 2015 at 10:48 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
Hi Maciej, On 25 June 2015 at 19:48, Maciej Fijalkowski <fijall@gmail.com> wrote:
This might be what you have in mind, but note that this case could be supported generically from RPython (without hacking at the PyPy source): when the RPython program starts, simply copy all global variables. I think that this would also make a copy of the JIT and the GC. For example, the GC is controlled mostly by a prebuilt IncrementalMiniMarkGC instance, which is a global variable. It's actually very easy to do (it's done in STM for example) but at the cost of one extra indirection for every prebuilt constant access. Trying to reduce this cost is more challenging (but on the other hand probably too small to measure anyway). A bientôt, Armin.
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@gmail.com> wrote:
Ran into a similar concept concern while doing some proof of concept work for my company. The approach that looked the most promising/easiest for a clean pypy state (both rpython internal and python globals) was to embed the sandbox controller and have it call out/create a new sandbox for each unit of isolated code. Although if you control the python code, reworking it such that it does not share global state is perhaps the best idea. On Thu, Jun 25, 2015 at 10:48 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
Hi Maciej, On 25 June 2015 at 19:48, Maciej Fijalkowski <fijall@gmail.com> wrote:
This might be what you have in mind, but note that this case could be supported generically from RPython (without hacking at the PyPy source): when the RPython program starts, simply copy all global variables. I think that this would also make a copy of the JIT and the GC. For example, the GC is controlled mostly by a prebuilt IncrementalMiniMarkGC instance, which is a global variable. It's actually very easy to do (it's done in STM for example) but at the cost of one extra indirection for every prebuilt constant access. Trying to reduce this cost is more challenging (but on the other hand probably too small to measure anyway). A bientôt, Armin.
participants (4)
-
Armin Rigo -
Eric Driggers -
Maciej Fijalkowski -
Yicong Huang