This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Nir Soffer, vstinner, walkhour
Date 2017-07-24.23:14:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1500938062.67.0.20622362549.issue30931@psf.upfronthosting.co.za>
In-reply-to
Content
On my PR 2854, Nir added these comments (extract):

"And now we try to read from close dispatcher. I think we should wait for #2804 (...)"

Sorry, I don't understand. My PR fixes described the bug that you described in msg298682:

"If a dispatchers is closed and and a new dispatcher is created, the new dispatcher may get the same file descriptor. If the file descriptor was in the ready list returned from poll()/select(), asyncore may try to invoke one of the callbacks (e.g. handle_write) on the new dispatcher."

About reading from closed dispatcher: sorry, I don't know the asyncore concurrency model, but I know the asyncio concurrency model. In asyncio, I don't see why a "dispatcher" would affect any "unrelated" dispatcher. Said differently: if a dispatcher A closes the dispatcher B and dispatcher B is "readable", the read event will be handled anyway. The "close event" will be handled at the next loop iteration. The oversimplified asyncio model is "each iteration is atomic".

Closing a dispatcher calls its del_channel() which removes its file descriptor from the asyncore map.

--

If I understand correctly, the *current behaviour* depends on the file descriptor order, since select.select() and select.poll.poll() returns ordered file descriptors (smallest to largest). If a dispatcher A is called and closes a dispatcher B, the dispatcher B is called or not depending on the file descriptor. If A.fileno() < B.fileno(), B is not called. If A.fileno() > B.fileno(), B was already called. Am I right?

What is the use case of a dispatcher closing another one? What is the consequence on my PR? Does the dispatcher B expects to not be called to read if it was already closed?

I see that close() also immediately closes the underlying socket. Does it mean that my PR can triggered OSError since we try recv() on a closed socket?
History
Date User Action Args
2017-07-24 23:14:22vstinnersetrecipients: + vstinner, Nir Soffer, walkhour
2017-07-24 23:14:22vstinnersetmessageid: <1500938062.67.0.20622362549.issue30931@psf.upfronthosting.co.za>
2017-07-24 23:14:22vstinnerlinkissue30931 messages
2017-07-24 23:14:22vstinnercreate