Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: how did blocking IO become such a problem?

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


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

The "blocking IO problem" has been there forever. It all comes back to the fact that asynchronous signals are a fundamentally flawed concept.

To illustrate the problem, imagine your parents/boss/significant-other could press a button on their phone at any time that would immediately, irrevocably and without warning cause your car to do a U-turn and return to your home/work regardless of where you were; the traffic conditions; your inputs to the controls; or your desire to not do so. Imagine the chaos as your car decides to take you back the wrong way back up the freeway.

That is what signals do!

Signals can and will interrupt your code at any point and leave data structures and communications channels in broken, corrupted and irrecoverable states.

At the C level, this can be mitigated to some extent by the careful and judicious use of signal masks to prevent interrupts at critical moments. But 1) it takes considerable effort to do this well; 2) if a signal arrives whilst a mask is in force, the signal is lost. And to solve that requires the programmer to implement some kind of signal queuing or deferral mechanism.

This is the reason for Perl's SAFE SIGNALS. Perl uses a lot of 'fat' internal data-structures that frequently require several different modifications to be made for them to remain in a coherent, usable state. If Perl allows signals to occur at any time, then it can result in (for example) hash structures that have had nodes removed, but the key count not correctly updated; or array size doubling that gets interrupted before all the values from the old array have been copied to the new one. And many more forms of irrecoverable internal state corruption.

This problem (with signals) was there from the very outset. Hence why *nix programs with frequently start a whole new process (fork) in order to do something seemingly trivial -- eg. perform IO. Because then they can interrupt (signal) it, safe in the knowledge that they can throw away the process and so not have to deal with the corruption caused by the interruption.

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 :)

As for the resistance of venerable old masters to threading, you'll have to ask them to know for sure, but in part it may be because the early threading libraries on *nix were rubbish; in part because it means learning something new.


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?


Comment on Re: how did blocking IO become such a problem?
Re^2: how did blocking IO become such a problem?
by Anonymous Monk on Feb 17, 2012 at 10:57 UTC

    As for the resistance of venerable old masters to threading, you'll have to ask them to know for sure, but in part it may be because the early threading libraries on *nix were rubbish; in part because it means learning something new.

    and part lack-of-love for other platforms :)

Re^2: how did blocking IO become such a problem?
by zentara (Archbishop) on Feb 17, 2012 at 11:55 UTC
    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
      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.

Re^2: how did blocking IO become such a problem?
by educated_foo (Vicar) on Feb 21, 2012 at 05:03 UTC
    I mostly agree with you, but...
    As for the resistance of venerable old masters to threading, you'll have to ask them to know for sure, but in part it may be because the early threading libraries on *nix were rubbish; in part because it means learning something new.
    Separate address spaces with explicit sharing are much easier to reason about than a single address space with implicit sharing. Accepting the latter in exchange for faster context switches is often a mistake.
      ... in exchange for faster context switches ...

      If that were all threading bought you, I'd agree. But it isn't. It isn't even the primary benefit.

      The primary benefit is the simplified code that results from having each logical part of your application run as a simple linear flow or loop, with only that state it needs, visible to it.

      The second benefit is the ability to prioritise some of those logical flows over others, secure in the knowledge that when something is ready to be done, it will get done in a timely fashion, within the priorities specified.

      Old timers tend to concentrate on the perceived -- usually second-hand -- problems, rather than the very real benefits.


      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?

        The primary benefit is the simplified code that results from having each logical part of your application run as a simple linear flow or loop, with only that state it needs, visible to it. The second benefit is the ability to prioritise some of those logical flows over others,
        Event-loop programming usually feels kind of contorted to me, too, but separate processes share both of these advantages. Better, processes make interaction between your program and the OS simpler w.r.t. I/O, signals, and scheduling than threads (which map to OS contexts in different ways on different platforms). Separate address spaces are more useful in C than in Perl, but they're still nice.
        The primary benefit is the simplified code that results from having each logical part of your application run as a simple linear flow or loop, with only that state it needs, visible to it.

        True, but is that not true of fork as well? Neither one distorts your code the way "Everything's a callback! Hooray!" does.

        The difficulty arises when attempting to share information between threads and processes. Then you run into locking and the possibility of data inconsistency. Sometimes I'd rather deal with that than with event-driven programming, and other times I wouldn't.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (7)
As of 2014-09-22 11:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (190 votes), past polls