Bug#691765: Bindings don't seem to release the GIL when doing I/O
Control: tags -1 +upstream -patch Hi Here's the answer from Tobias (upstream): the problem is that the getopt library is not threadsave and most rrdtool functions except rrd_xport still use getopt ... so in order to make it all thread save the other functions would also have to be switched over to the new getopt used in rrd_xport ... then the beast would be threadsafe. Therefore, it's a good thing the python lock is kept, at the moment.
Bug#691765: Bindings don't seem to release the GIL when doing I/O
Control: tags -1 + patch Hello Enrico. On Mon, Oct 29, 2012 at 02:49:03PM +0100, Enrico Zini wrote: I was auditing the rrdtool binding code to check if they could be used in a python thread without locking the entire application via the GIL. Extensions are supposed to release the GIL lock around potentially blocking I/O operations like reading or writing a file, so that other Python threads can run in the meantime. I went through rrdtoolmodule.c and didn't see any use of Py_BEGIN_ALLOW_THREADS or thread-related functions, so it looks like python-rrdtool would keep all concurrent threads of the application blocked during I/O. http://docs.python.org/2/c-api/init.html#threads has more details. This isn't an urgent issue for me personally: we're using pyrrd through the 'external' backend, which uses Popen to invoke rrdtool, and Popen correctly releases the GIL during I/O. However, I felt like I should share what I found during my little code review. How does this look? https://github.com/nirgal/rrdtool-1.x/commit/8949308812a0205dd356cefbe2eb2888012ee742 Not asking for a full review, a that's the idea would be cool. ^^ -- Nirgal 3 YKINMYKBYKIOK
Bug#691765: Bindings don't seem to release the GIL when doing I/O
On Thu, Aug 27, 2015 at 08:18:16PM +, Jean-Michel Vourgère wrote: How does this look? https://github.com/nirgal/rrdtool-1.x/commit/8949308812a0205dd356cefbe2eb2888012ee742 Not asking for a full review, a that's the idea would be cool. ^^ That's definitely the idea :) Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Bug#691765: Bindings don't seem to release the GIL when doing I/O
forwarded 691765 rrd-develop...@lists.oetiker.ch thanks Hi, On Mon, Oct 29, 2012 at 02:49:03PM +0100, Enrico Zini wrote: I was auditing the rrdtool binding code to check if they could be used in a python thread without locking the entire application via the GIL. Extensions are supposed to release the GIL lock around potentially blocking I/O operations like reading or writing a file, so that other Python threads can run in the meantime. I went through rrdtoolmodule.c and didn't see any use of Py_BEGIN_ALLOW_THREADS or thread-related functions, so it looks like python-rrdtool would keep all concurrent threads of the application blocked during I/O. http://docs.python.org/2/c-api/init.html#threads has more details. This isn't an urgent issue for me personally: we're using pyrrd through the 'external' backend, which uses Popen to invoke rrdtool, and Popen correctly releases the GIL during I/O. However, I felt like I should share what I found during my little code review. Thanks for sharing this. With this email, I'm forwarding the issue to the upstream developers mailinglist for further attention. Cheers, Sebastian -- Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin signature.asc Description: Digital signature
Bug#691765: Bindings don't seem to release the GIL when doing I/O
Package: python-rrdtool Version: 1.4.7-2 Severity: normal Hello, I was auditing the rrdtool binding code to check if they could be used in a python thread without locking the entire application via the GIL. Extensions are supposed to release the GIL lock around potentially blocking I/O operations like reading or writing a file, so that other Python threads can run in the meantime. I went through rrdtoolmodule.c and didn't see any use of Py_BEGIN_ALLOW_THREADS or thread-related functions, so it looks like python-rrdtool would keep all concurrent threads of the application blocked during I/O. http://docs.python.org/2/c-api/init.html#threads has more details. This isn't an urgent issue for me personally: we're using pyrrd through the 'external' backend, which uses Popen to invoke rrdtool, and Popen correctly releases the GIL during I/O. However, I felt like I should share what I found during my little code review. Ciao, Enrico -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-rrdtool depends on: ii libc62.13-35 ii librrd4 1.4.7-2 ii python 2.7.3~rc2-1 python-rrdtool recommends no packages. python-rrdtool suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
