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.