Re: 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?

Replies are listed 'Best First'.
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	[reply]
Re^3: how did blocking IO become such a problem? by BrowserUk (Patriarch) 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?	[reply] [d/l]
A reply falls below the community's threshold of quality. You may see it by logging in.
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.	[reply]
Re^3: how did blocking IO become such a problem? by BrowserUk (Patriarch) on Feb 21, 2012 at 12:23 UTC
... 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?	[reply]
Re^4: how did blocking IO become such a problem? by chromatic (Archbishop) on Feb 21, 2012 at 15:59 UTC
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.	[reply] [d/l]
Re^5: how did blocking IO become such a problem? by BrowserUk (Patriarch) on Feb 21, 2012 at 17:57 UTC
Re^4: how did blocking IO become such a problem? by educated_foo (Vicar) on Feb 21, 2012 at 15:19 UTC
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.	[reply]
Re^5: how did blocking IO become such a problem? by BrowserUk (Patriarch) on Feb 21, 2012 at 18:00 UTC
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 :)	[reply]