Am 13.09.2013 12:57, schrieb Dmitry Olshansky:
13-Sep-2013 13:57, Sönke Ludwig пишет:
Am 12.09.2013 19:55, schrieb Sean Kelly:
On Sep 12, 2013, at 8:34 AM, Bienlein <jeti...@web.de> wrote:
About thread-multiplexing... You find a lot in Google when
searching for socket multplexing, but not when searching for
thread-multiplexing. Maybe I coined the term myself (don't know
any more) when reading the section here:
http://golang.org/doc/effective_go.html#goroutines
"Goroutines are multiplexed onto multiple OS threads so if one
should block, such as while waiting for I/O, others continue to
run. Their design hides many of the complexities of thread
creation and management."
The trick in D is that because statics are thread-local by default,
any multiplexed app like this that expects its static data to remain
consistent across calls is likely to fail. I've mentioned fiber-local
storage here in the past, but it's a tricky problem. But I think it's
one that we will need to sort out for things like this to work as the
user expects them to.
Until we have something built-in, I've implemented a template based
solution for task local storage (same as fiber local storage, but the
lifetime is different as fibers get recycled for consecutive tasks):
http://vibed.org/api/vibe.core.core/TaskLocal
I do hope O(n) is a typo and it should be O(1).
Anyhow what n stands here for?
n would be the number of variables declared. There is a linear
initialization cost and in the naive predecessor implementation, an AA
with Variants was used to store the values, which is why I've mentioned
efficiency at all.
