On Wed, Feb 4, 2015 at 12:45 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: >> But your comment is interesting because, as I understand it, a >> non-blocking web server is simply a matter of setting timeouts on >> sockets, catch the exceptions and move on. > > Now I think you might have some misconceptions about nonblocking > networking I/O. Nonblocking I/O is done using asynchronous, or > event-driven, programming. Your code reacts to external stimuli, never > blocking, mostly just sleeping. The reactions are defined in callback > routings, aka listeners, aka event handlers.
Not strictly true - that's just one convenient way of doing things. A callback/event-handler structure lets you write a bunch of listeners that coexist effortlessly, but it's not the only way to do non-blocking I/O, and it's certainly not an intrinsic part of the concept. That said, though, it is a VERY convenient way to lay things out in the code. The Pike system I offered, and most of the older multiplexed-I/O systems I've used, did work that way. It just isn't something that non-blocking necessarily implies. >> I don't know why wouldn't that be possible with python stdlib ? > > It is possible using the low-level facilities. However, the traditional > high-level facilities are built on multithreading, which (as a rule) is > based on blocking I/O. Multithreading is another way to cope with the same problem of wanting to deal with different sockets on a single CPU, but I don't think it's inherently a part of any of Python's own high-level facilities - not that I can think of, at least? However, in terms of common programming models, yes, multithreading+blocking I/O is an effective way to write code, and will therefore be commonly used. I wish more people had grown up on OS/2 instead of (or as well as) Windows or Unix. Threading is not such a bugbear as a lot of people seem to think. Yes, some platforms have traditionally had poor implementations, and to be sure, you don't want to mix threading and forking without a *lot* of care, but threads aren't inherently bad. They're a useful tool in the toolbox. Sometimes non-blocking I/O is the right thing to do; sometimes threads suit the problem better; other times, something else again. ChrisA -- https://mail.python.org/mailman/listinfo/python-list