Browse thread
[Caml-list] The Bytecode Interpreter...
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Gerd Stolpmann <info@g...> |
| Subject: | Re: [Caml-list] The Bytecode Interpreter... |
Am Samstag, den 29.10.2005, 10:41 +1300 schrieb Jonathan Roewen: > Hi, > > I have a question about the vmthreads package. I've been looking at > the source of schedule.c, and am making a small understanding of how > it works. > > Is it true that this supports true pre-emption of threads (e.g. even > during a GC cycle)? No. Preemption can only happen in the main loop of the bytecode interpreter. > Also, would it be safe to build an ISR framework > that could wake up a thread waiting on an interrupt to be triggered? The problem is you need realtime behaviour. That means your ISR thread must have a higher priority than other threads, i.e. you need a realtime-aware scheduler. Second, also memory management must be realtime-aware. This is the difficult part. How to handle the case when the interrupt occurs within a GC cycle? The minor GC is not the problem, because it is very fast, and has an upper limit on the time spent in it. Major GC: In principle, you can stop it at any time. You should probably do so when the interrupt occurs. And then? The ISR must not allocate memory in this case, because the memory manager cannot give it to you in this moment (major GCs are triggered from minor GCs, so the minor heap is currently full). It is very difficult to write ISR code that does not allocate any memory. Maybe a way out is to have further minor heaps only for this purpose (one heap per realtime thread), but this raises further questions (how to get it empty again when the ISR is over? What to do if it becomes full? What to do if you still need a major heap block?) Compactification: I think this GC mode is totally incompatible with real time. You cannot stop it, and it takes a very long time. Gerd > Like if I somehow got it to act like a file descriptor... > > Jonathan > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Telefon: 06151/153855 Telefax: 06151/997714 ------------------------------------------------------------