Re: GC leak?

VI> The JVM provides (if memory serves) just one construct to manage VI> concurrency, the monitor, which uses locks on objects to do its VI> job. Voila! Support for multithreading, etc. in one fell swoop since VI> everything else is implemented in class libraries. VI> So, yes, concurrency is about data safety and liveliness, but the VI> theory of the underlying implementation can be quite simple. Now, are we talking about MT support that's hidden from Emacs Lisp applications, or are we talking about exposing multithreading at the application level? My first full-time job was at Xerox, programming in Mesa, which had threading primitives; synchronization was based on monitors. Since then, I've continued writing multithreaded code, first with Mach, then with the Sprite and Solaris kernels. One thing I've learned from all that is that multithreaded code is hard to get right, at least with the commonly available primitives. You first need to be careful about making sure that protected data is really protected (unless you're using a language like Mesa, where the compiler can check for you). And you need to structure the code carefully to avoid deadlocks. And you need to think harder about race conditions. *And* even if you come up with some clean design that's easy to program to, odds are that it won't last. Someone will complain about how performance isn't as good as it could be, and it's because some lock is held when it doesn't need to be. The fix will mostly likely involve adding complexity to the formerly clean design, thereby making it easier to introduce races and deadlocks in the future. Beware. There Be Dragons Here. mike _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta