[issue42110] race condition in ThreadChildWatcher (default) and MultiLoopChildWatcher

2020-10-22 Thread Alan Jenkins
Alan Jenkins added the comment: Put the other way, if you wanted to fix this bug in ThreadedChildWatcher, and go as far as allowing cancelling Process.wait(), followed by kill() / send_signal(), then I think you need - * siginterrupt(SIGCHLD, 1) * not to mind about any random C code that

[issue42110] race condition in ThreadChildWatcher (default) and MultiLoopChildWatcher

2020-10-22 Thread Alan Jenkins
Alan Jenkins added the comment: There's one way to fix this in MultiLoopChildWatcher (but not ThreadedChildWatcher). Make sure the waitpid() runs on the same thread that created the subprocess. Prototype: https://github.com/sourcejedi/cpython/c

[issue42110] race condition in ThreadChildWatcher (default) and MultiLoopChildWatcher

2020-10-21 Thread Alan Jenkins
New submission from Alan Jenkins : ## Test program ## import asyncio import time import os import signal import sys # This bug happens with the default, ThreadedChildWatcher # It also happens with MultiLoopChildWatcher, # but not the other three watcher types. #asyncio.set_child_watcher

[issue35749] Rewrite asyncio signal handler

2020-10-21 Thread Alan Jenkins
Alan Jenkins added the comment: Here's a simple test case that fails on the main branch. https://github.com/sourcejedi/cpython/commit/50184ea3b354fd775866d036ccee058ec6734927 > the patch assumes that python signal handler will be called *before* reading > from self-pipe. >

[issue36704] logging.FileHandler currently hardcodes errors='strict'

2019-04-26 Thread Alan Jenkins
Alan Jenkins added the comment: Oops. I assumed logging.raiseExceptions == True (the default) actually raises exceptions, but it doesn't. It prints the exception to stderr and continues. E.g. traditional UNIX daemons run with stderr connected to /dev/null. Consider during develo

[issue36704] logging.FileHandler currently hardcodes errors='strict'

2019-04-23 Thread Alan Jenkins
Alan Jenkins added the comment: > [**] dnf developers did not appear to work on the correctness issue they > found. It might be a bug in gettext. Nitpick: sorry, I read too quickly. dnf *did* fix the specific correctness issue, as well as setting raiseExceptions = false. It is exp

[issue36704] logging.FileHandler currently hardcodes errors='strict'

2019-04-23 Thread Alan Jenkins
New submission from Alan Jenkins : ## Problem description ``` import os import logging logging.basicConfig(filename='example.log',level=logging.DEBUG) for name in os.listdir(): logging.error('Hypothetical syntax error at line 1 of file: {}'.format(name)) ```

[issue26838] sax.xmlreader.InputSource.setCharacterStream() does not work?

2016-04-24 Thread Alan Jenkins
Alan Jenkins added the comment: Looks like this is documented elsewhere and fixed in 3.5. https://fossies.org/diffs/Python/3.4.3_vs_3.5.0/Doc/library/xml.sax.reader.rst-diff.html -- status: open -> closed ___ Python tracker <http://bugs.pyth

[issue26838] sax.xmlreader.InputSource.setCharacterStream() does not work?

2016-04-24 Thread Alan Jenkins
New submission from Alan Jenkins: python3-3.4.3-5.fc23-x86_64 So far I spelunked here. Starting from <https://github.com/kurtmckee/feedparser/issues/30>. I experimented with using setCharacterStream() instead of setByteStream() setCharacterStream() is shown in documentation but exer