On Sun, Dec 03, 2006 at 02:56:11AM +0100, Pierre THIERRY wrote: > Scribit Jonathan S. Shapiro dies 02/12/2006 hora 12:34: > > I'm not convinced that the language should provide support for > > threading or co-routines. > > I thought that because of possibly bad interactions between GC and > threads, it would be needed for a GCed language to provide threading > support (instead of being able to use any external thread support, like > you could in C/C++).
I think I remember Shap saying that the kernel will be written in BitC and for various reasons the kernel can't have (and in practise probably doesn't want) a general garbage collector---additionally the hardware will also impose it's own threading model. This suggests that there will be a core of BitC that will be usable without garbage collection. The current BitC generator is very happy to put everything on the heap, but I'd be interested to know how long this behaviour is expected to survive. Also interesting is the "dup" procedure. This explicitly returns a heap allocated (shallow?) copy of its parameter. I thought that EROS processes can have several space banks (not sure if this is right term, but the intention is that there are several places that memory can come from depending on who you want to be held accountable for it), if so which one is chosen to be used when you "dup" a value. The C language is notable in its absence of a general purpose allocator and I'm wondering if BitC should follow suit; maybe leaving "dup" like functionality to some clever use of type classes (which can be automatically generated by the compiler like the Eq and Show classes are for data types in Haskell) and library code. Or is all this in the spec already and I'm just being stupid! Back to Pierre's question; why can't you just bundle the threading and GC into a single library. The problem with this is that once it becomes possible to replace the GC/threading model then different libraries will want different implementations and getting them to work in the same bit of code becomes problematic. I think I remember that EROS tended to put what would have been a library under Unix into its own process. This would solve the problem and also have the advantage of allowing appropriate selection of threading models/memory management. Sam _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
