New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
possible deadlock in python IO implementation #47868
Comments
BufferedWriter from Lib/io.py is thread-safe, but... the Python Well, this problem is really not critical since only developers Solution: use C implementation of Lib/io.py (from Python 2.6) to avoid Example with py3k trunk:
>>> import _lsprof
>>> prof=_lsprof.Profiler(42)
>>> prof.enable()
# _lsprof calls 42()
# -> 42 is not callable
# -> call PyErr_WriteUnraisable(<42 is not callable>)
# -> deadlock Traceback example: #6 0x080ecb30 in PyThread_acquire_lock (lock=0x820f550, waitflag=1) ceval hook: Python/ceval.3403:
PCALL(PCALL_CFUNCTION);
if (flags & (METH_NOARGS | METH_O)) {
...
} else {
PyObject *callargs;
callargs = load_args(pp_stack, na);
READ_TIMESTAMP(*pintr0);
C_TRACE(x, PyCFunction_Call(func,callargs,NULL)); <= **here**
READ_TIMESTAMP(*pintr1);
Py_XDECREF(callargs);
} |
Yes indeed. We could use an RLock to avoid the problem but RLock's are
I guess it's out of question. However, Buffered{Reader,Writer,Random} |
Oops, I forgot to update PyInit__Thread() with my new time:
Here is the new patch |
Ooops again, I uploaded my patch to the wrong issue! The new patch is |
see the python-3000 thread I just started asking for opinions on this. |
So if we consider that RLock is fast enough (see my C version of RLokc |
Selon STINNER Victor <report@bugs.python.org>:
I tried your test and it seems to lock when using the Python implementation of Also, your RLock implementation has to be finished before going further ;) |
We might as well bite the bullet and include a short, minimalist RLock |
Here is a patch. The RLock implementation is naive and as simple as I don't want to make a decision on this alone, so someone please advise. |
(I have to add that the patch makes small reads about 60-80% slower) |
I hope that this issue will be fixed by io-c (io library rewritten in |
The test (io_deadlock.patch) pass on the io-c branch \o/ |
Yes, this is solved in the io-c branch. Antoine, do you think we should |
I don't know. The RLock is a lot slower than the normal non-recursive |
2009/2/28 Antoine Pitrou <report@bugs.python.org>:
I'm +0. The deadlock will only affect people specifically messing with |
Since io-c has been merging, I'm lowering priority. |
Why not fixing this issue? The issue is rare (only occurs when using profiling |
2009/3/4 STINNER Victor <report@bugs.python.org>:
See msg82934. |
Ooops, I wanted to write: "Why not *closing* this issue?", sorry. |
I suppose we might as well. If anyone wants to fix the Python |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: