On Thu, 2005-09-01 at 00:57 +0700, Constantine Plotnikov wrote: > >There is a single heap. There is no language-supported concurrency, so > >there is one stack and zero threads. > > > > > Possibly I'm missing something. C does not have lanuguage supported > concurrency, however it is possible to write multithreaded programs > using it. If BitC is a general purpose system programming language, it > might happen that some BitC programs will be written for platforms that > support/require multithreading.
It is true that people write these things in C. It is also true that these codes rely on behavior that is NOT part of the language specification. Each platform makes platform-specific extensions to compiler and runtime to support this. We rejected direct support for concurrency in BitC for two reasons: 1. We have never seen a language concurrency model that we think was "done right." 2. Appropriate concurrency support tends to be domain specific. 3. We wanted to solve the single-thread problem first. 4. Formally capturing the semantics of a concurrent language is MUCH harder than a single-threaded language. > >This is a tricky question. My view is that we *must* specify this for > >the "manual storage" operating mode, but that we should not specify this > >for the "managed storage" mode. > > > > > Where I can read about "manual" or "explicit" storage model? Nowhere, yet. > Will dynamic linking with grounded definitions be allowed? If yes, will > be there additional restrictions of dynamic linking? I do not know what you mean by "grounded definitions", so I do not know how to answer this question. > Just a small off-topic question, are these storage managers written in > BitC or can be they written in BitC? The current one is written in C++, because it was written to support the prototype implementation. It is unlikely that this collector could be rewritten in BitC, because it requires operations that are (a) unsafe, and (b) not expressable within the language. The first issue is solvable through the prover. The second issue is going to require some real thought to resolve. Eventually, I would *like* to be able to write the collector in BitC. > >Yes. Part of my hesitation to specify too early is that I want to know > >that we can implement the requirements. > On other hand until it is formally specified, it cannot be discussed > with enough rigor. So it might be a good idea to have this information > in the specification with mark "under consideration". Constantine: it is simply too early to do this for some of this stuff, and much of the rest of what you wanted already appears in the document. Storage layout, for example, is specified. > In Java there is other complication. User might want to have resource > not to be garbage collected while reference is being held. In Java if > native resource is being wrapped by object, finalization often closes > resource handle. Java finalization has been gotten wrong by javasoft several times. Finalization is also a problem to specify in any non-concurrent runtime. This is currently an issue under discussion on connection with BitC, and I should probably raise it on the list. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
