Re: "Stackless" XEmacs?
Jerry James writes:
> 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. Fixing those would give us
the same benefits as this "stackless" architecture.
Well, my understanding is that stackless Python actually exposes those
"threads" to Python. I don't care how it's implemented, but I really
would like for (a) certain long-blocking applications like Gnus and VM
to more cooperative, and (b) to be able to get information about their
state, maybe, from another thread.
Yes, threads are certainly hard. I'm not necessarily suggesting
we
dive into using them. I'm suggesting that the stackless approach is
[no panacea].
Oh, of course not. I'm not pushing the stackless approach per se, I'm
just throwing out ideas. This one rang my chimes because (a) I have
immense respect for the Python development team and (b) because a 3rd
party brought it up in emacs-devel.
I've got too many irons in the fire right now. Let's
postpone this
discussion for a few weeks.
I'll assume that's a promise.
These damn Steves (Baur and Yegge, specifically) are giving me an
itch....
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta