Jep, threading would be really hard to do. Especially given that we are serializing system calls through the stdin/out. A blocking system call in the hypervisor process would make it impossible to switch to another thread. (unless you decide to still execute until the next system call in the other thread.)
An alternative what is working pretty well for me is using one asyncronous event loop in the sandbox. (like Twisted Matrix, tornado, etc...), and instead of epoll or select, you use any blocking operation like open() or read() in the sandbox. Cheers, Jonathan 2012/12/21 Armin Rigo <ar...@tunes.org> > Hi Zhoucan. > > On Fri, Dec 21, 2012 at 8:15 AM, 周灿 <zhoucan1...@gmail.com> wrote: > > But i feel puzzled pypy sandbox is not compatible with all the standard > > libs(such as threading), since pypy does not allow interperter to load > native C modules. > > There is some confusion here. The regular PyPy (no sandbox) comes with: > > * all standard libraries, rewritten not a C code, but as internal RPython > code; > > * for third-party modules, a way to load the standard CPython C > extension modules (slowly). > > The PyPy with sandbox comes with almost no such module. If your > application requires a specific standard library module and you can > verify that it is safe to include it, you might consider adding it, > with the proper tweaks. For example, the "thread" module might in > theory be added, saying "threadsafe=True" on all external C functions > that it calls; but this needs efforts to make sure that it is safe. > > On the other hand, third-party CPython C extension modules are a no-no > for the sandboxed PyPy. Maybe this could change, but it's even more > work. > > > A bientôt, > > Armin. > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > http://mail.python.org/mailman/listinfo/pypy-dev >
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
