[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: call/cc



You write:
> Quoth Kragen Sitaker on Tuesday, 11 December:
> : Are you counting captured continuations
> : that will be resumed later, or not?  
> 
> No, they are not kernel-scheduled entities.
> 
> : ... 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...

Well, the thing I'm wondering about is whether the performance hit
comes from the "kernel-scheduled" part or just the "context-switching"
part: register save and restore, decreased locality of reference, that
kind of thing.  call/cc, like any other way of implementing a
user-level threads package, still costs context-switching.

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

At the site of any possibly-blocking operation, many, but not all, of
which are I/O.  How much harder to read this makes your code depends
largely on how often you do possibly-blocking operations.  E's
"promises" (see erights.org) seem like they might help bridge the gap,
but I haven't tried programming in E.

It also depends on how well your language supports closures.  Writing
explicit CPS is more of a problem in C than in JavaScript or Scheme.

In any case, the original discussion was about call/cc-implemented
threads versus kernel threads.  Do you think that code using threads
implemented with call/cc tends to be more maintainable than similar
code using kernel threads?  Why?

> 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.

I like to think I already have CPS in my repertoire; I've written a
few thousand lines in C and JavaScript that way, and I still think
it's hard to read and understand.  You can't write compound
expressions, your only control structure is "goto", and the extra
noise in your source code introduced by defining functions, anonymous
and otherwise, all over the place makes it still harder to follow.