Browse thread
Faking concurrency using Unix forks and pipes (ray tracing results)
[
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: | Brian Hurt <bhurt@j...> |
| Subject: | Re: [Caml-list] Faking concurrency using Unix forks and pipes (ray tracing results) |
Jonathan Bryant wrote: > > On Jun 4, 2007, at 12:33 PM, Benedikt Grundmann wrote: > >> >> It looks a bit more complex, but that's just to avoid big strings in >> case of big messages >> (e.g. with the "simple" interface you end up with the "same" content >> in memory twice). > > > I think big strings are unavoidable in this case. They can be broken > up at the protocol level for sending, but a large data structure is > going to be marshaled into a big string. As far as same content in > memory twice, that should be the case for pure values even in a > regular OCaml program. As for mutable values, they shouldn't be sent > over a channel to begin with. Once channels are available though, > creating a synchronous mutable cell is only a few lines of code. > (Check out Reppy's book/papers). I'm wondering if inversion of control isn't an answer here. The idea is to have a function of type buf_t -> string -> unit. Instead of building up a giant string, the of_* functions would call this function on small strings. Not unlike Buffers. But instead of building up in memory, these function would fill a buffer and then send it off. Brian