Changes by Graham Dumpleton graham.dumple...@gmail.com:
--
nosy: +grahamd
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16500
___
___
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16500
___
___
Python-bugs-list mailing list
2012/11/20 Christian Heimes rep...@bugs.python.org
IFF we are going to walk the hard and rocky road of exception handling,
then we are going to need at least four hooks and a register function that
takres four callables as arguments: register(prepare, error, parent,
child). Each prepare()
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16500
___
___
Changes by Amaury Forgeot d'Arc amaur...@gmail.com:
--
nosy: +amaury.forgeotdarc -Amaury.Forgeot.d'Arc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16500
___
Richard Oudkerk added the comment:
IFF we are going to walk the hard and rocky road of exception handling,
then we are going to need at least four hooks and a register function that
takres four callables as arguments: register(prepare, error, parent,
child). Each prepare() call pushes an
Christian Heimes added the comment:
Amaury:
PyPy doesn't handle exceptions in hooks. Is there a reason why PyPy goes for
the simplistic approach?
Richard:
An error callback has the benefit that the API can notice the hooks that some
error has occurred. We may not need it, though.
I can think
Amaury Forgeot d'Arc added the comment:
PyPy doesn't handle exceptions in hooks.
Is there a reason why PyPy goes for the simplistic approach?
Probably because nobody thought about it.
At the moment, there is only one 'before', one 'parent' hook (so the FILO order
is simple), and three
Gregory P. Smith added the comment:
I think you are solving a non-problem if you want to expose exceptions from
such hooks. Nobody needs it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16500
Antoine Pitrou added the comment:
I think you are solving a non-problem if you want to expose exceptions from
such hooks. Nobody needs it.
Agreed.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16500
Christian Heimes added the comment:
Your suggestion is that the hooks are called as:
for hook in hooks:
try:
hook()
except:
try:
sys.excepthook(*sys.exc_info())
except:
pass
That makes the implementation much easier. :)
--
Christian Heimes added the comment:
Thanks Richard!
My first reaction was YAGNI but after I read the two tickets I now understand
the need for three different hooks. I suggest that we implement our own hooks
like the http://linux.die.net/man/3/pthread_atfork function, especially the
order of
Richard Oudkerk added the comment:
Note that Gregory P. Smith has written
http://code.google.com/p/python-atfork/
I also started a pure python patch but did not get round it posting it. (It
also implements the fork lock idea.) I'll attach it here.
How do you intend to handle the
Gregory P. Smith added the comment:
I would not allow exceptions to propagate. No caller is expecting them.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16500
___
Gregory P. Smith added the comment:
pthread_atfork() cannot be used to implement this. Another non-python
thread started by a C extension module or the C application that is
embedding Python within it is always free to call fork() on its own with
zero knowledge that Python even exists at all.
Christian Heimes added the comment:
Meh! Exception handling takes all the fun of the API and is going to make it
MUCH more complicated. pthread_atfork() ignores error handling for a good
reason. It's going to be hard to get it right. :/
IFF we are going to walk the hard and rocky road of
New submission from Christian Heimes:
I propose the addition of an 'afterfork' module. The module shall fulfill a
similar task as the 'atexit' module except that it handles process forks
instead of process shutdown.
The 'afterfork' module shall allow libraries to register callbacks that are
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16500
___
___
Python-bugs-list mailing list
Richard Oudkerk added the comment:
pthread_atfork() allows the registering of three types of callbacks:
1) prepare callbacks which are called before the fork,
2) parent callbacks which are called in the parent after the fork
3) child callbacks which are called in the child after the fork.
I
19 matches
Mail list logo
