[issue42513] Socket.recv hangs
Barney Stratford added the comment: Sure. So, I'm using STOMP to connect to a messaging server. STOMP uses heartbeats to detect and close failed connections. The problem was that if the connection fails before the protocol has set up its heartbeats then there's nothing to stop the whole thing hanging. I had a timeout on the socket.create_connection, thinking this would protect against this edge-case, but it wasn't sufficient. STOMP is such a simple protocol that it's often worth writing your own code to handle it. Indeed, this is actively encouraged. My own STOMP code is about 250 lines in a single source file, compared to nearly 3500 lines in 13 files for stomp.py. I very much prefer to simplify things as much as possible, and smaller is almost always better in my view. Simplify! So, I kept seeing this very occasional hang-up in my code, and probing it with gdb showed that the execution was always stuck inside the poll. Of course it was, as that's where it sits to wait for something to happen. Then I was lead astray by finding that website, so I saddled up to save the world, as one does in such situations. -- ___ Python tracker <https://bugs.python.org/issue42513> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42513] Socket.recv hangs
Barney Stratford added the comment: Instrumented code shows that the poll is in fact working completely correctly, and I've run into a documented edge-case in an unrelated area. Hence, closing the bug report and cancelling the pull request. -- resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42513> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42513] Socket.recv hangs
Barney Stratford added the comment: The instrumented code froze today, so I'm finally able to probe the bug. Despite what that website said, it's looking like checking the return fron the poll syscall isn't the problem here. I'm probably going to close this bug report as not a bug, but want to check fully before I do so. -- ___ Python tracker <https://bugs.python.org/issue42513> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42513] Socket.recv hangs
Barney Stratford added the comment: Still waiting for the instrumented code to hang. It sometimes runs for a month or two before freezing. -- ___ Python tracker <https://bugs.python.org/issue42513> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42513] Socket.recv hangs
Change by Barney Stratford : -- keywords: +patch pull_requests: +22448 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23567 ___ Python tracker <https://bugs.python.org/issue42513> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42513] Socket.recv hangs
New submission from Barney Stratford : import socket self.__socket = socket.create_connection ([host, port], 1) value = self.__socket.recv (4096) This code sometimes hangs despite having a non-None timeout specified. GDB says: (gdb) bt #0 0x76d33c94 in __GI___poll (fds=0x7ea55148, nfds=1, timeout=1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x001e8014 in poll (__timeout=, __nfds=, __fds=, __fds=, __nfds=, __timeout=) at /usr/include/arm-linux-gnueabihf/bits/poll2.h:46 #2 internal_select (writing=writing@entry=0, interval=, connect=0, connect@entry=4156908, s=) at ../Modules/socketmodule.c:745 #3 0x001ec588 in sock_call_ex (s=s@entry=0x76979d68, writing=writing@entry=0, sock_func=sock_func@entry=0x1e736c , data=0x7ea551b0, data@entry=0x7ea551a8, connect=connect@entry=0, err=err@entry=0x0, timeout=100) at ../Modules/socketmodule.c:840 #4 0x001ed394 in sock_call (data=0x7ea551a8, func=0x1e736c , writing=0, s=0x76979d68) at ../Modules/socketmodule.c:3287 #5 sock_recv_guts (s=s@entry=0x76979d68, cbuf=, len=, flags=) at ../Modules/socketmodule.c:3287 #6 0x001ed51c in sock_recv (s=0x76979d68, args=) at ../Modules/socketmodule.c:3318 Googling for this problem turned up this: https://stackoverflow.com/questions/56038224/poll-waits-indefinitely-although-timeout-is-specified If we look at socket module.c line 756 (Python 3.7.9 version), we see that we're indeed not checking for the pollfd.revents, and are therefore missing socket errors. PR coming up in a few days. -- components: Library (Lib) messages: 382145 nosy: Barney Stratford priority: normal severity: normal status: open title: Socket.recv hangs type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue42513> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41149] Threads can fail to start
New submission from Barney Stratford :
>>> import threading
>>> class foo (object):
... def __bool__ (self):
... return False
... def __call__ (self):
... print ("Running")
...
>>> threading.Thread (target = foo ()).start ()
The expected result of these commands would be for the thread to print
"Running". However, in actual fact it prints nothing at all. This is
because threading.Thread.run only runs the target if it is True as a
boolean. This is presumably to make the thread do nothing at all if
the target is None. In this case, I have a legitimate target that is
False as a boolean.
I propose to remove the test altogether. The effect of this is that
failure to set the target of the thread, or setting a non-callable
target, will cause the thread to raise a TypeError as soon as it is
started. Forgetting to set the target is in almost every case a bug,
and bugs should never be silent.
PR to follow.
--
components: Library (Lib)
messages: 372521
nosy: BarneyStratford
priority: normal
severity: normal
status: open
title: Threads can fail to start
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue41149>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35162] Inconsistent behaviour around __new__
New submission from Barney Stratford :
>>> class Eggs (object):
... def __init__ (self, number):
... self.__number = number
... def __repr__ (self):
... return "{} eggs".format (self.__number)
...
>>> Eggs (4)
4 eggs
>>> del Eggs.__new__
Traceback (most recent call last):
File "", line 1, in
AttributeError: __new__
>>> # As expected
...
>>> Eggs (4)
4 eggs
>>> Eggs.__new__ = None
>>> del Eggs.__new__
>>> Eggs (4)
Traceback (most recent call last):
File "", line 1, in
TypeError: object() takes no parameters
>>> # Wrong! Eggs has no __new__, so this should respond as earlier
...
This bug seems to be because the slotdef isn't updated when __new__ is deleted.
--
messages: 329231
nosy: Barney Stratford
priority: normal
severity: normal
status: open
title: Inconsistent behaviour around __new__
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue35162>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24727] Expand readline module
Changes by Barney Stratford barney_stratf...@fastmail.fm: -- components: +Extension Modules -Library (Lib) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24727 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24727] Expand readline module
New submission from Barney Stratford: I have a use case where a daemon thread needs to write periodic updates to sys.stdout. I'd prefer it not to print in the middle of a command being typed. In order to achieve this, I have added to the readline module. There is now a function to determine whether we are reading a line, and one to call rl_forced_update_display. These functions enable me to say (in the daemon thread): def describe (indicator): if readline.reading_line (): print () print (indicator.description) readline.forced_update_display () else: print (indicator.description) I have read PEP7, and have made patchtest on my patch. -- components: Library (Lib) files: patch.txt messages: 247424 nosy: Barney Stratford priority: normal severity: normal status: open title: Expand readline module type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40029/patch.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24727 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
