Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
resolution: - wont fix
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7739
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
-1 on releasing the GIL around strftime(). Until we have an implementation
that can support multiple locales and multiple timezones, people will work
around this limitation by messing up with the TZ environment variable
STINNER Victor victor.stin...@haypocalc.com added the comment:
I understand your last comment as wanting to keep the GIL while calling
tzset(), but release it around the strftime() call.
Yes
You still want to apply your patch, right?
http://sourceware.org/bugzilla/show_bug.cgi?id=4350
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Victor,
I understand your last comment as wanting to keep the GIL while calling
tzset(), but release it around the strftime() call. You still want to apply
your patch, right?
I think the problem is not with a
STINNER Victor victor.stin...@haypocalc.com added the comment:
It appears that the stall happens due to time.strftime call, which internally
opens
a file ('/etc/localtime')
In the GNU libc, strftime() calls tzset() and tzset() uses a lock to be thread
safe. Yes, releasing the GIL before
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file15954/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7739
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
Here you have a patch releasing the GIL for the call to strftime().
--
keywords: +patch
Added file: http://bugs.python.org/file15959/time_strftime_gil.patch
___
Python tracker
STINNER Victor victor.stin...@haypocalc.com added the comment:
time_tzset() might also release the GIL, but:
- i hope that multithreaded programs don't call regulary tzset() in different
threads
- time_tzset() calls tzset() and inittimezone()
- inittimezone() modify the time module
New submission from Doron Tal doron.tal.l...@gmail.com:
I've encountered a hung of python process for more than a second. It appears
that the stall happens due to time.strftime call, which internally opens a file
('/etc/localtime'). I think it is best if the GIL would have been released to
Antoine Pitrou pit...@free.fr added the comment:
You might want to investigate which C library call opens this file, and propose
a patch to release the GIL before doing that call. As far as I can tell, Python
itself does not open /etc/localtime in any place.
--
nosy: +pitrou
Martin v. Löwis mar...@v.loewis.de added the comment:
I'd also be curious why it takes a second to open /etc/localtime. That sounds
like a bug in the C library, or a mismanaged system.
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
Doron Tal doron.tal.l...@gmail.com added the comment:
We didn't prove this point yet, currently it's merely circumstantial.
The application calls strftime few dozen times each second from different
threads. We spot the stall using another two threads, the first takes a time
stamp before calling
12 matches
Mail list logo
