Re: "Stackless" XEmacs?

> > 1. You have to choose between two painful alternatives. > > a. [...] > > > b. A scheduler that only runs inside of well-defined functions, meaning > > that a given stack can hog the CPU for arbitrary amounts of time. > > It's not obvious to me that this wouldn't be a big win in XEmacs. > This isn't a realtime OS where you need to discipline badly-behaved > threads; it's a single-user application where judicious use of > cooperative multithreading might permit big wins from a few tweaks. Yes, but we already do that! That's what the select()/poll() driven event loop is all about: find out what I/O is ready to go, then run the handler to drive it. There are some places where we don't follow discipline and allow the process to block rather than defer activity to a later iteration of the event loop.

> Because threads are hard. I could see using threads for certain > subsystems (eg, redisplay, and assuming Marcus and Olivier are up for > it, GC), but having true threads in the Lisp interpreter will be hard > (unless we're willing to replace the whole thing). Yes, threads are certainly hard. I'm not necessarily suggesting we dive into using them. I'm suggesting that the stackless approach is (a) a lot more work than fixing our discipline with respect to our current architecture for about the same benefit; and (b) a lot less work but with much less benefit than going to a threaded architecture.