Browse thread
Fwd: [Caml-list] Faking concurrency using Unix forks and pipes
-
Jonathan Bryant
-
Erik de Castro Lopo
- Jonathan Bryant
-
Erik de Castro Lopo
[
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: | Jonathan Bryant <jtbryant@v...> |
| Subject: | Re: [Caml-list] Faking concurrency using Unix forks and pipes |
> >> I do have worries about the efficiency of this though: >> when marshaling a closure across a socket to another process, it >> must marshal all the necessary state as well. I would imagine this >> has the potential to get slow if there was much state to marshal >> (i.e., a closure marshaled referencing a large data structure). > > This is a potential problem. This is like so many language features > that if misused, can lead to huge performance degradations. Knowing > about the problem beforehand allows programmers to avoid it. Just throwing out an idea, so someone who is more familiar with the GC/runtime correct me if this can't be done, but what about a smaller separate heap in shared memory that is reserved for concurrent data? Maybe you could declare a type stype 'a tree = | Node of 'a * 'a tree * 'a tree | Leaf of 'a that is always allocated in the shared heap, and have a separate GC thread that manages that heap. Could that GC be concurrent without affecting the performance of non-concurrent data? --Jonathan