continuations and C extensions?

the immutable GvR intones:
Continuations involving only Python stack frames might be supported, if we can agree on the the sharing / copying semantics. This is where
I don't know enough see questions at #2 above).
What if there are native C calls mixed in (eg, list.sort calls back to myclass.__cmp__ which decides to do a call/cc). One of the really big advantages of Python in my book is the relative simplicity of embedding and extensions, and this is generally one of the failings of lisp implementations. I understand lots of scheme implementations purport to be extendible and embeddable, but in practice you can't do it with *existing* code -- there is always a show stopper involving having to change the way some Oracle library which you don't have the source for does memory management or something... I've known several grad students who have been bitten by this... I think having to unroll the C stack safely might be one problem area. With, eg, a netscape nsapi embedding you can actually get into netscape code calls my code calls netscape code calls my code... suspends in a continuation? How would that work? [my ignorance is torment!] Threading and extensions are probably also problematic, but at least it's better understood, I think. Just kvetching. Sorry. -- Aaron Watters ps: Of course there are valid reasons and excellent advantages to having continuations, but it's also interesting to consider the possible cost. There ain't no free lunch.
participants (1)
-
Aaron Watters