[OT] poll() vs. AIO (was: [PATCH] ash: clear NONBLOCK flag from stdin when in foreground)

[Laurent Bercot]

 Beware, holy wars ahead. :)


> One of the big reasons I now consider threads one of the best (but not
> always "the best", of course) approach to non-blocking operations is
> that they're the only idiom that allows one to mechanically transform
> blocking code into a non-blocking form.

 Multiprocessing does that too.
 As I already wrote to this list (and in answer to you), the only case
where I think multithreading is worth it is when both the following are
true:
 - you have a lot of complex, multi-state things happening in parallel
   (so, using an event-driven loop would be too complicated)
 - you have a lot of shared structured data that would make IPCs complex
   (so, multiprocessing would be too complicated).

 When the second condition is not true, creating one process per blocking
operation is justified - that's the inetd/tcpserver/tcpsvd approach.
True, a new process is heavier than a new thread, but it has its
advantages: in a new process, you can do absolutely what you want to
achieve your goal, including execve()ing another program that might not
even be written in the same language. And you won't step on anyone else's
toes, the kernel protects you.
 I also find it cleaner and more unix-ish to have several smaller
executables that can call one another rather than one multithreaded
executable. But, again, it's a question of taste.

 The only situation when threads shine is when your parallel operations
are both too complex to be performed in an event-driven loop AND too
intricated to be performed in separate processes. From my point of view,
if you have reached that point of complexity, then something's wrong and
you need to redesign your program in a simpler way. XD

(I kid, I kid. But I haven't yet had to write a program where I've felt
multithreading was the best solution. I'm thinking of writing an IRC
server someday and that might change things, the amount of shared data
seems just too big for a multiprocess approach to be efficient.)


> Anything else potentially
> requires major rewrites of core program logic. This matters a lot more
> often than one might think, when you inherit or want to integrate
> library code that was intended for sequential/standalone processing
> into an interactive program or persistent server.

 Multiprocessing achieves this too.


> One of the most significant results of this observation in relation to
> writing *new* code is the fact that, with threads, you can actually
> use stdio FILEs for most or all of your io, even in programs dealing
> with asynchronous events from many sources, reducing or eliminating
> the need to roll your own buffering.

 From my point of view, you have it backwards, probably because of your
dedication to standards.
 stdio sucks, badly. Why WOULD you want to use it for most or all of
your IO ? To me, your saying "writing threaded code allows me to use
stdio" sounds like "by contorting myself, I can fit into that ill-tailored
suit".
 I have written my own buffer library a long time ago, without even
really thinking about asynchronism - just because I was fed up with
stdio. And when I needed to perform asynchronous IO, lo and behold, unlike
stdio, my buffer library was still working and usable. I have never come
back to stdio since, and never had any regrets.

-- 
 Laurent