Hi Dmitry,

On 9 June 2015 at 05:10, Dmitry Sagalovskiy <dmitry@getgrist.com> wrote:
> More generally, my team needs to decide if we can rely on the pypy sandbox to use in our product. It seems brilliantly designed, fast, and overall impressive. But there are these gaps in missing sandbox wrappers (there are others too, fcntl is just one that I don't know how to avoid). And I noticed some code that indicates that it is not supported on Windows -- is that the case?
> What are the sandbox's prospects, within the larger future of pypy?

The sandbox code is there and "mostly working", but it is lacking a
champion.  It has been in this state for many years now (it is
actually impressive that it still roughly works).  Realistically,
though, to answer the question of its prospects, it depends entirely
on whether someone would be ready to become involved in PyPy and help
maintain and develop it.  As usual with Open Source, we can't predict
when (and if) this will occur.  From our point of view, it seems to
attract occasional attention like yours, but we just have too many
things to work on.

> If anyone can suggest what I might be doing wrong, I would greatly
> appreciate.

You're not doing anything wrong, just stumbling on a mixture of old
and new code.  In the case of 'pypy_jit_depthmap_add', it's because we
recently added vmprof support and didn't think about sandboxing.  The
fix is probably easy: we need a few "sandboxsafe=True" keyword
arguments in rpython/jit/backend/llsupport/codemap.py.  The issue with
'fcntl' is more obscure and involves much older code.  In that case we
need the sandboxed interpreter to ask the outside what to do---which
should occur automatically, but doesn't, for reasons I'm still
investigating.  I suspect it's related to the XXX in the comment of
select_function_code_generators() in rpython.translator.c.node.  (I
think with minimal effort we can finally get rid of the "oldstyle"
functions mentioned there.)


A bientôt,

Armin.