3 ms·

Unlike Erlang which copies messages, and Pony which uses reference capabilities, BeAPI used a pragmatic approach where BMessages shared a kernel memory pool. A

Unlike Erlang which copies messages, and Pony which uses reference capabilities, BeAPI used a pragmatic approach where BMessages shared a kernel memory pool. Add the ability to filter messages and dynamically retarget messages, and you get a PRACTICAL (vs academic) Actor model. I wouldn't say it was half-hearted and primitive, on the contrary.

dnautics 7y ago
Erlang isn't exactly academic, or impractical. And the BMessages themselves did not share the kernel memory pool, it was the thread system (or BLooper if you will), but only some of the primitives. In fact, BeOS was kind of split brained. You could send a message to a thread either through the kernel send command (which had a limited queue length) or a one which use local shared memory (which effectively did not). That is, of course rather dangerous, since there are no protections on that memory (it being C++). I don't miss the segfaults that I experienced time after time and strange stateful consistency errors from when I was programming in the BeOS, and I don't miss biting my knuckles when having to recast data as (void*) in order to send it to another thread, now that I'm programming in ERTS. I do however strongly appreciate the experience, because it was a hell of a lot of fun, and, importantly, I learned that you can't use a buffered matrix mult to save on memory allocations, because you don't know that your preemptive kernel won't kick you out midway through the matrix mult and start filling the bins with data from the other thread. I would say that half of the reason why I am really adept at identifying race conditions in erlang is that I've seen them all, and worse, in BeOS. And the BeOS runtime does not have half of the resilience and fault isolation properties that Erlang has, which is what I mean by "half hearted and primitive".

dnautics 7y ago

Erlang isn't exactly academic, or impractical. And the BMessages themselves did not share the kernel memory pool, it was the thread system (or BLooper if you will), but only some of the primitives. In fact, BeOS was kind of split brained. You could send a message to a thread either through the kernel send command (which had a limited queue length) or a one which use local shared memory (which effectively did not). That is, of course rather dangerous, since there are no protections on that memory (it being C++). I don't miss the segfaults that I experienced time after time and strange stateful consistency errors from when I was programming in the BeOS, and I don't miss biting my knuckles when having to recast data as (void*) in order to send it to another thread, now that I'm programming in ERTS. I do however strongly appreciate the experience, because it was a hell of a lot of fun, and, importantly, I learned that you can't use a buffered matrix mult to save on memory allocations, because you don't know that your preemptive kernel won't kick you out midway through the matrix mult and start filling the bins with data from the other thread. I would say that half of the reason why I am really adept at identifying race conditions in erlang is that I've seen them all, and worse, in BeOS. And the BeOS runtime does not have half of the resilience and fault isolation properties that Erlang has, which is what I mean by "half hearted and primitive".