Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

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

by zentara (Archbishop)
on Feb 17, 2012 at 11:55 UTC ( #954515=note: print w/ replies, xml ) Need Help??


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

Imagine having to clone your phone every time before making a call, so that you could throw it away afterwards if you received a second call during the first :)

True, but these are not real entities, like phones, they are easily created and discarded magnetic fields. With the increase in modern processor speeds, surely we could spare a few extra cpu cycles, to make that happen to avoid the problem.

By the way, what would be a good way to generate a blocked I/O condition, for testing? Download a big file, then drop your network?


I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh


Comment on Re^2: how did blocking IO become such a problem?
Re^3: how did blocking IO become such a problem?
by BrowserUk (Pope) on Feb 17, 2012 at 14:16 UTC
    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?

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

        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?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://954515]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (6)
As of 2014-12-23 05:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (135 votes), past polls