Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 07 Sep 2017 01:18:19 +0000
From:      bugzilla-noreply@freebsd.org
To:        python@FreeBSD.org
Subject:   maintainer-feedback requested: [Bug 222112] lang/python36 selectors.select() does not block on named pipes / mkfifo
Message-ID:  <bug-222112-21822-PMCqH6CFRD@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-222112-21822@https.bugs.freebsd.org/bugzilla/>
References:  <bug-222112-21822@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help 
Jeff Kletsky <jeff+freebsd@wagsky.com> has reassigned Bugzilla Automation
<bugzilla@FreeBSD.org>'s request for maintainer-feedback to FreeBSD Python
<python@FreeBSD.org>:
Bug 222112: lang/python36 selectors.select() does not block on named pipes /
mkfifo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222112



--- Description ---
An instance of selectors.select() blocks as expected until data is ready on=
 a
named pipe or a regular file. On FreeBSD 11.1-RELEASE-p1 it does not block
after that data has been read from a named pipe (but does continue to block
with a regular file).=20

This is both unexpected and inconsistent with at least behavior under Mac O=
S X,
which continues to block as expected with both a named pipe and a regular f=
ile.

Observed behavior:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* my_selectors.select() blocks as expected until data is written to the pipe
* the data is read from the pipe
* my_selectors.select() no longer blocks

Expected behavior:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* my_selectors.select() would block until there was more data written to the
pipe


Same behavior is seen with the "default" selectors.KqueueSelector as well as
with explicitly using a selectors.PollSelector (Mac OS X default).


Impact:
=3D=3D=3D=3D=3D=3D=3D
* No clear way to use select from Python to "read when ready" from a named =
pipe
* Programs that rely on select may have very unexpected behavior


Workarounds:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(none at this time)


Environment:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FreeBSD 11.1-RELEASE-p1
python3-3_3
python36-3.6.1_4

jailed or host system, same behavior
venv or not, same behavior


To replicate:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(warning, this will spew to the terminal until interrupted if commands-in i=
s a
named pipe)

$ rm commands-in
$ mkfifo commands-in
(run the program, below)
$ echo "Something" >> commands-in   # ">" also fails

using 'touch' to obtain a regular file will demonstrate the regular-file
behavior

key_event_list is retained for visibility in debugger
timeout=3DNone is the default, made explicit to confirm not the issue
"If timeout is None, the call will block until a monitored file object beco=
mes
ready.=E2=80=8B"

See also https://forums.freebsd.org/threads/62377/

Example Python 3 code follows:

import logging
import selectors


def test():

    command_pipe =3D 'commands-in'

    logging.basicConfig(level=3Dlogging.INFO)
    logger =3D logging.getLogger()

    logger.info(f"Opening command pipe: '{command_pipe}'")
    with open(command_pipe, 'r') as cp:
	select_cp =3D selectors.DefaultSelector()
	select_cp.register(cp, selectors.EVENT_READ)
	while True:
	    key_event_list =3D select_cp.select(timeout=3DNone)
	    line =3D cp.readline()
	    logger.info(f"Read: '{line}'")


if __name__ =3D=3D '__main__':

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-222112-21822-PMCqH6CFRD>