[Python-3000] iostack and sock2

[tomer filiba]

hey

> One thing I would like to raise is the issue of KeyboardInterrupt. I find
> very inconvenient that a normal application doing a very simple blocking
> read from a socket can't be interrupted by a CTRL+C sequence. Usually, what
> I do is to setup a timeout on the sockets (eg. 0.4 seconds) and then simply
> retry if the data has not arrived yet. But this changes the code from:

from my experience with linux and solaris, this CTRL+C problem only
happens on windows machines. but then again, windows can't select()
on anything but sockets, so there's not gonna be a generic solution.
setting timeouts has some issues (inefficiency, platform dependency,
etc.). but it's a good point to take into account. i'll see where that fits.


-tomer

On 6/5/06, Giovanni Bajo <rasky at develer.com> wrote:
> tomer filiba wrote:
>
> > some time ago i wrote this huge post about stackable IO and the
> > need for a new socket module. i've made some progress with
> > those, and i'd like to receive feedback.
> >
> > * a working alpha version of the new socket module (sock2) is
> > available for testing and tweaking with at
> > http://sebulba.wikispaces.com/project+sock2
> >
> > * i'm working on a version of iostack... but i don't expect to make
> > a public release until mid july. in the meanwhile, i started a wiki
> > page on my site for it (motivation, plans, design):
> > http://sebulba.wikispaces.com/project+iostack
> > with lots of pretty-formatted info. i remember people saying
> > that stating `read(n)` returns exactly `n` bytes is problematic,
> > can you elaborate?
>
> Hi Tomer, this is great stuff you're doing! It's something that's really
> needed in my opinion. Basically, right now there's only a convention of
> passing around duck-typed things which have a "read" method, and that's all!
> It's nice to better define this duck-typed interface, and it seems you're
> doing very good progress on that. I hope I have more time to properly
> comment on this later (I'll wait for the first iteration of comments).
>
> One thing I would like to raise is the issue of KeyboardInterrupt. I find
> very inconvenient that a normal application doing a very simple blocking
> read from a socket can't be interrupted by a CTRL+C sequence. Usually, what
> I do is to setup a timeout on the sockets (eg. 0.4 seconds) and then simply
> retry if the data has not arrived yet. But this changes the code from:
>
> data = sock.recv(10)
>
> to:
>
> while 1:
>    try:
>       data = sock.recv(10)
>    except socket.timeout:
>       # just so that CTRL+C is processed
>       continue
>    else:
>       break
>
> which is IMO counter-intuitive and un-pythonic. It's such a convoluted code
> that it happened once to me that another programmer collapsed this back into
> the bare sock.recv() because he couldn't immediately see why that complexity
> was required (of course, comments might have helped and stuff, but I guess
> you see my point).
>
> I believe that this kind of things ought to work by default with the minimum
> possible amount of code. Specifically, I think that the new iostack should
> allow blocking mode without trapping CTRL+C by default (which is the normal
> behaviour expected). I'm not sure if it's worth doing the auto-retry trick
> internally (bleah), or implement blocking calls with a call to select() so
> that you can also wait on signals, or something like that; I don't have a
> suggestion at this point, but I thought it was worth to raise the issue.
> --
> Giovanni Bajo
>
>