Re^4: how did blocking IO become such a problem?

[sundialsvc4]

in reply to Re^3: how did blocking IO become such a problem?
in thread how did blocking IO become such a problem?

(up-voted)

... “whereas,” if I may presume to impose upon your very apt analogy... “meanwhile, performance or no, the switchboard operator downstairs is quite matter-of-factly handling fifteen calls ‘simultaneously,’ and doing her nails and watching her tea-timer, all ‘at the same time.’”

To me, asynchronous I/O is the only reasonable way to handle things such as this.   (And who, frankly, really cares about the POSIX so-called “standard” anyhow?)   At any particular millisecond, you are either waiting for another light on the switchboard to light up (and you really do not care which one it is ...), or you are waiting to hear the little bell which tells you that your tea is ready (while doing your nails).

After all, a CPU (which can quite effortlessly react in terms of nanoseconds), can support many hundreds of “simultaneous” connections (which are timed at-best in terms of milliseconds), more-than-plenty fast enough, even though (from its point of view...) it is actually servicing them “one at a time.”

Here, the entire uber-messy business of “truly being interrupted” is neatly avoided.   Even if the tea-timer goes off “during” the call, the operator can easily deal with it after she has dealt with the call.   The telephone operator never actually has to stop whatever she is doing in order to finish making her tea... she merely has to notice that, sometime during the period of time when she was dealing with her last call, the little bell chimed.   The actual processing cycle, although it is completed very fast and might vary considerably from one iteration to the next, is never actually aborted.   And this reduces the whole thing to something that is quite reliable indeed.

[BrowserUk]

Sorry, but it is blindingly obvious that you have no idea what is meant by asynchronous IO.

Specifically, it is not a select loop. To correct your analogy, it is definitively not the following:

Imagine employing an intern to sit in the reception of your office block, and have him or her verbally relay each part of each telephone call coming in or out of the build. Ie. there is no direct connection between the outside lines and the internal extensions.

When Mrs. Brown calls to speak to accounts. The receptionist listens to her question and then calls Accounts and repeats it. Then listens to Accounts response and repeats it on the outside line to Mrs. Brown.

At the same time, s/he, the receptionist, is doing the same thing between: HMRC and the Audit Department; and between the Chairman and his wife; and between Goods-in and the Post Office; the head of HR and a sacked employee; the post guy and his boyfriend; the cook and a wholesaler; and the Chairman and his girlfriend; ...

Needless to say, "polishing nails" doesn't get a look in.

That is a fairly accurate analogy of a select loop. All state visible from the one point in the program. No way to prioritise one event over another; or one event type over another, much less one particular conversation over another. All your eggs in one basket. Always fighting fires.

No, Asynchronous IO, also known as Overlapped IO, is a quite, quite different beast.

I suggest you look it up -- you know, do a little research, ensure that you know what it is you're pontificating about -- before you torture any more incorrect analogies to death.

[sundialsvc4]

I think that you spend far too much time presupposing that I don’t know what I am talking about, when I choose to use an analogy that strikes you as “a little odd.”   (I regret to inform you that you are not the most knowledgeable individual on this planet; nor am I.)   And you certainly waste not a single opportunity to criticize my simple homilies.

No, obviously, a select() loop is not the same thing as “asynchronous I/O,” which is simply the idea of starting an I/O operation without blocking the requesting process or thread until it completes.   But both it and “the telephone switchboard operator” are a simple but effective illustration of the idea of being able to do many things “at once” with but a single thread or process (say...) being responsible for all.

As you very-correctly pointed out in this thread, “signaling” a process in Unix/Linux is a very disruptive thing to do and it almost always causes severe timing-related problems that might well not be reproducible ... except, of course, in production, where they will invariably happen every time.   A unit of work, be it an asynchronous I/O request or a select() packet or even a light on a telephone switchboard, is not equivalent to (nor does it in any way require...) a dedicated thread or process.   A very simple sequential event-handling procedure .. of which select() is, of course, probably the most common example .. can service a great number of “simultaneous” requests and, since the internal logic is not parallel, a whole phalanx of otherwise messy issues (mutexes and locks and so forth) simply vanish.

Tell ’ya what ... try this sometime ... read my posts (or for that matter, just about anyone else’s that you have lately responded to), and don’t respond at all.   Don’t correct them.   In particular, don’t teach them the error of their ways.   If you want a web-site where your word is king, simply set up one of your own.   Add your own comments, but if someone says something that’s technically not the perfect way to say it, just let their own words rest in peace.

[BrowserUk]

I don't presuppose that you don't know what you talk about. And I do read your posts.

It is from reading your posts that it is obvious -- to anyone with any detailed knowledge; ie. anyone who has ever written a program to use these techniques -- that you have no real understanding of them at all.

You may have perused the glossary and learnt a few keywords; scanned the management summary enough to gain a little context; and have sufficient English skills to dress them together with ``lot's'' "of" 'different' quotes and _s^t_y^l_i^s_tⁱ_c devices and some flowery analogies to fool the unknowing into a few up-votes, but it stands out like a sore thumb that there is no real understanding behind your words.

It is not just obvious from what you write; but also from the fact that you've never once posted any code in example of your pseudo-theoretical advices. And from the fact that you never counter argue the subject in support of your statements; but only attempt to distract with meta-discussion. And I am not the only one who can see it. I can only down-vote you once!

You Sir, are a wannabe. But you're either too old, or too lazy or too recalcitrant to actually to do any research -- much less actually write any programs -- and get a real understanding of that about which you pontificate. You're not even a has-been. More, a never-will-be.