global interpreter lock

[Bryan Olson]

Mike Meyer wrote:
 > Bryan Olson <fakeaddress at nowhere.org> writes:
 >> > Bryan Olson writes:
 >> > Trivially, an 'if' statement that depends upon input
 >> >>data is statically predictable. Use of async I/O means makes the
 >> >>programs execution dependent upon external timing.
 >>Mike Meyer wrote:
 >> > Yes, but that depenency is tied to a single point - the select
 >> > call. The paths after that are statically predictable. This makes the
 >> > code very managable.
 >>Wow -- I could not disagree more. Returning back to some single
 >>point for every possibly-blocking operation is painful to manage
 >>even for simple GUIs, and humanly intractable for sophisticated
 >>services.
 >
 > I'd be interested in what you're trying to do that winds up as
 > unmanagable.

I'd like to call a utility in someone else's code, but it might
do something that could block. I find re-writing everyone's code
into a state-machine that can trap back to the central I/O loop
and later resume where it left off, to be hard to manage. When
I'm writing my own base classes, I find it hard to support the
back-to-the-I/O-loop-and-resume thing so that method over-rides
can call blocking operations when they need to.


 > There are clearly things select+async IO is unsuitable
 > for. You may be running into problems because you're trying to use it
 > in such an environment. For instance, it's not clear to me that it
 > will work well for any kind of GUI programming, though I've had good
 > look with it for command line interfaces.

Uh, not sure where you're coming from there. Are you unaware of
the 'event loop' in the GUI's, or unaware that it's async I/O.

 >>Select is certainly useful, but it scales badly and isn't as
 >>general as better tools.
 >
 > It can't take advantage of multiple CPUs. I've not run into scaling
 > problems on single-CPU systems.

Select() is linear-time in the number of sockets to be checked
(not just the number found to be ready). There's a good write-up
of the problem and solutions Google-able as "The C10K problem".


 >> > [...] I'm calling the tools available in most programming
 >> > languages for dealing with it primitive.
 >> > We need better tools.
 >>Agreed, but if 'select' is someone's idea of the state of the
 >>art, they have little clue as to the tools already available.
 >
 > Well, share!

Uh, where have you been? I keep explaining that concurrency
systems have improved vastly in recent years. For a long time,
the most sophisticated software services generally have used
multiple lines of execution, and now that's mostly in the form
of threads. No one actually disagrees, but they go right on
knocking the modern methods.


-- 
--Bryan