Re: call/cc

[Tony Kimball <address@hidden>]

Quoth Kragen Sitaker on Tuesday, 11 December:

: I don't quite understand the connection.  What are you counting as
: "threads" in your NThreads? 

For simplicity's sake, read "Kernel threads".

: Are you counting captured continuations
: that will be resumed later, or not?  

No, they are not kernel-scheduled entities.

: How about other user-level thread
: packages that don't require a round trip into and out of the kernel for
: each context switch?

I addressed this in my immediately previous mail to the list, in reply
to S. Alexander Jacobsen.

: While I've written some of the examples you mention myself, I don't
: really know where the extra CPU time goes in multithreaded systems.

The only way to answer that categorically is to compare profiling
information, inclusive of kernel profiling, for a representative
sample of multithreaded servers, with profiling information for a
representative sample of purely asynchronous servers.  That would be
a master's thesis, at least, at many institutions these days.

: I think your (later) point about threads being harder to maintain is
: debatable; writing complex asynchronous code (without call/cc, that is)
: forces your program into explicit CPS, which is a major pain.

Only at the site of I/O operations.  

Frankly, I like CPS style, and will happily mix it with object code,
so it's like water off a proverbial duck, but I understand that you
raise a valid point:  You pay for performance and versatility by
adding a coding idiom to your repetoire.  Some may not like the price.