Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

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

by BrowserUk (Pope)
on Feb 17, 2012 at 14:16 UTC ( #954541=note: print w/replies, xml ) Need Help??

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

With the increase in modern processor speeds, surely we could spare a few extra cpu cycles, to make that happen to avoid the problem.

That was only a tongue-in-cheek analogy, but the problem of with the leap into the stack and transfer the program flow to some other place in the program at any given instance in time remains.

Perhaps a better analogy is allowing the audience, or even the actors on stage, to take phone calls in the middle of a performance. The thought trains involved are even more nebulous patterns of firing neurons, but still the impact is not confined to the individual, but upon all other partisipants. Audience and players combined. And recovery is just as difficult.

There are much better ways of dealing with the indeterminate nature of blocking IO: namely. Asynchronous IO which is available on most platforms, and has been for years. But I don't think it ever made it into that dead dodo of a standard that is POSIX?

By the way, what would be a good way to generate a blocked I/O condition, for testing?

The very simplest is my $input = <STDIN>;.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Replies are listed 'Best First'.
Re^4: how did blocking IO become such a problem?
by sundialsvc4 (Abbot) on Feb 21, 2012 at 03:57 UTC


    ... “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.

      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.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?

        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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://954541]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2018-05-25 21:31 GMT
Find Nodes?
    Voting Booth?