Comments on: A story of simplification and abstraction (stackless timeouts) https://www.robg3d.com/2014/01/a-story-of-simplification-and-abstraction-stackless-timeouts/ Blog of Rob Galanakis (@robgalanakis) Sun, 29 Jun 2014 22:35:09 +0000 hourly 1 https://wordpress.org/?v=5.4.1 By: Rob Galanakis https://www.robg3d.com/2014/01/a-story-of-simplification-and-abstraction-stackless-timeouts/#comment-230721 Sun, 29 Jun 2014 22:35:09 +0000 http://www.robg3d.com/?p=1190#comment-230721 In reply to Jim Parris.

Hi Jim, you may need to grab the newest version from the BitBucket repo. Kristjan isn’t the most prompt with new pypi versions.

]]> By: Jim Parris https://www.robg3d.com/2014/01/a-story-of-simplification-and-abstraction-stackless-timeouts/#comment-230306 Fri, 13 Jun 2014 15:20:18 +0000 http://www.robg3d.com/?p=1190#comment-230306 Say now, what version of stacklesslib are you guys using then?

The version I have (the latest? stacklesslib-1.0.3-py2.7) does not have any such method as ‘timeout’ or similar.

]]> By: Adam Skutt https://www.robg3d.com/2014/01/a-story-of-simplification-and-abstraction-stackless-timeouts/#comment-228024 Sat, 11 Jan 2014 22:49:58 +0000 http://www.robg3d.com/?p=1190#comment-228024 Both. You can’t (generally) cancel blocking I/O, so you’re left with a stuck thread until the I/O call returns. You can’t even portably close the I/O channel from a second thread, ignoring the rather difficult locking required to even attempt such a task.

Ultimately, if your code uses an internal timeout to “give up” on an I/O operation, then you must have all the necessary machinery to deal with a stuck thread until the I/O operation completes, which may never happen.

]]> By: Rob Galanakis https://www.robg3d.com/2014/01/a-story-of-simplification-and-abstraction-stackless-timeouts/#comment-228023 Sat, 11 Jan 2014 21:45:30 +0000 http://www.robg3d.com/?p=1190#comment-228023 Well getting to the root of a problem rather than addressing the symptom deserves a whole post of its own (is a common theme on Raymond Chen’s blog) and I probably didn’t do enough of it in this case (I got caught up teaching him about thread/tasklet scheduling and stuff like that). I’m not sure what the resulting solution would have been, especially if it meant having to cut up some of his processing code which I suppose he wouldn’t have wanted to do on short notice (the first versions of internal customer service tools tend to be rush jobs).

What do you mean by cleanup being more difficult with blocking IO? You mean cleaning up the thread or tasklet that is blocked?

]]> By: Adam Skutt https://www.robg3d.com/2014/01/a-story-of-simplification-and-abstraction-stackless-timeouts/#comment-228022 Sat, 11 Jan 2014 21:31:44 +0000 http://www.robg3d.com/?p=1190#comment-228022 If the actual task was doing network I/O, then surely doing non-blocking I/O or using socket timeouts (where supported) is the simplest thing. In particular, it makes clean up vastly more easy over the blocking I/O case.

]]>