Am 03.03.2014 16:55, schrieb Bienlein:
On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote:
Just out of curiosity, what did you miss in vibe.d regarding fiber
based scheduling?
Hi Söhnke,
I'm thinking of developing a little actor library on top of D's
spawn/receive model for
Am 03.03.2014 22:58, schrieb Bienlein:
On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote:
Just out of curiosity, what did you miss in vibe.d regarding fiber
based scheduling?
There is something else I forgot to mention. One scenario I'm thinking
of is to have a large number of
On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote:
Just out of curiosity, what did you miss in vibe.d regarding
fiber based scheduling?
By the way is there a way to make use of vibe.d in something like
a local mode? I mean some in-memory mode without going through
TCP.
Thanks,
On Saturday, 8 March 2014 at 16:01:00 UTC, Bienlein wrote:
On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote:
Just out of curiosity, what did you miss in vibe.d regarding
fiber based scheduling?
By the way is there a way to make use of vibe.d in something
like a local mode? I mean
On Thursday, 13 February 2014 at 15:40:05 UTC, Sean Kelly wrote:
On Thursday, 13 February 2014 at 15:30:58 UTC, Bienlein wrote:
On Thursday, 6 February 2014 at 19:24:39 UTC, Sean Kelly wrote:
On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly
wrote:
Am 03.03.2014 11:31, schrieb Bienlein:
On Thursday, 13 February 2014 at 15:40:05 UTC, Sean Kelly wrote:
On Thursday, 13 February 2014 at 15:30:58 UTC, Bienlein wrote:
On Thursday, 6 February 2014 at 19:24:39 UTC, Sean Kelly wrote:
On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly
On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote:
Just out of curiosity, what did you miss in vibe.d regarding
fiber based scheduling?
Hi Söhnke,
I'm thinking of developing a little actor library on top of D's
spawn/receive model for creating threads, which is already
On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote:
Just out of curiosity, what did you miss in vibe.d regarding
fiber based scheduling?
There is something else I forgot to mention. One scenario I'm
thinking of is to have a large number of connections like more
than 100.000 I want
Am Tue, 04 Feb 2014 10:43:26 -0800
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 2/4/14, 10:05 AM, Sean Kelly wrote:
Support for green threads in std.concurrency is almost complete. I
should really just do the last bit of work. I imagine you could try out
the idea now
On Thursday, 6 February 2014 at 19:24:39 UTC, Sean Kelly wrote:
On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly wrote:
https://github.com/D-Programming-Language/phobos/pull/1910
Hello,
I have a little question about how pre-emption works with the
FiberScheduler. Let's say I
On Thursday, 13 February 2014 at 15:30:58 UTC, Bienlein wrote:
On Thursday, 6 February 2014 at 19:24:39 UTC, Sean Kelly wrote:
On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly
wrote:
https://github.com/D-Programming-Language/phobos/pull/1910
Hello,
I have a little question about
On Thursday, 13 February 2014 at 15:40:05 UTC, Sean Kelly wrote:
The API is able to context switch inside send and receive. So
if you aren't sending messages with some frequency then the
level of parallel execution will be fairly low. For apps like
this, it's possible that a more complex
Yes. The schedulers are required to maintain some data (one being
a message queue) for each thread they spawn. If the data is
requested from a thread the scheduler doesn't own, it's required
to return a thread-local copy instead. In short, any manually
created kernel thread will get its own
On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly wrote:
As for when this will be available... I will have a pull request
sorted out shortly, so you could start playing with it soon. It
being included in an actual release means a review and such, but
as this is really just a fairly
Here is a document about the scheduler design in Go:
https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw/edit
The C sources for the Go scheduler are here:
http://code.google.com/p/go/source/browse/src/pkg/runtime/proc.c?r=01acf1dbe91f673f6308248b8f45ec0564b1d751
What is nice about CSP is that you can proof that your code is
free of deadlocks. The Go guys have developed a tool that
parses the code and then tells you what it has found.
Note that the Go race detector isn't a static analysis tool that
identifies deadlocks at compile time; it instruments
On Thursday, 6 February 2014 at 13:00:51 UTC, logicchains wrote:
Note that the Go race detector isn't a static analysis tool
that identifies deadlocks at compile time; it instruments the
code and then detects race conditions at runtime. It's based on
the C/C++ ThreadSanitizer runtime library,
On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly wrote:
As for when this will be available... I will have a pull request
sorted out shortly, so you could start playing with it soon. It
being included in an actual release means a review and such, but
as this is really just a fairly
On Thursday, 6 February 2014 at 19:24:39 UTC, Sean Kelly wrote:
https://github.com/D-Programming-Language/phobos/pull/1910
x-posted to vibe.d newsgroup. Awesome!
On Wednesday, 5 February 2014 at 01:02:37 UTC, Sean Kelly wrote:
Okay, just for fun, here are some results with the new
scheduler.
I injected periodic yields into the code to simulate the
yielding that would happen automatically if the code was using
send and receive. First the code:
Hi
On Wednesday, 5 February 2014 at 10:56:23 UTC, Bienlein wrote:
On Wednesday, 5 February 2014 at 01:02:37 UTC, Sean Kelly wrote:
Okay, just for fun, here are some results with the new
scheduler.
I injected periodic yields into the code to simulate the
yielding that would happen automatically
On Wednesday, 5 February 2014 at 14:40:46 UTC, Sean Kelly wrote:
Sort of. std.concurrency uses the actor model. So it's
messaging, but not the CSP model used by Go. We should probably
offer both, but for now it's just actors. And because you
basically have one channel per thread, the limiting
On Wednesday, 5 February 2014 at 15:38:43 UTC, Bienlein wrote:
On a very well equipped machine 10.000 threads is about the
maximum for the JVM. Now for D 1.000.000 kernel threads are not
a problem!? Well, I'm a D newbie and a bit confused now... Have
to ask some questions trying not to bug
How We Went from 30 Servers to 2: Go. Link:
http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html
Heh, here is more interesting interpretation of this article
http://versusit.org/go-vs-ruby
On Tuesday, 28 January 2014 at 17:25:35 UTC, Russel Winder wrote:
It seems goroutine like process and channels are coming to C++:
https://github.com/ahorn/cpp-channel
This is interesting, but you can bring that sort of approach to
some other language as well. Here is a simple approach to get
On Tuesday, 4 February 2014 at 09:37:16 UTC, Bienlein wrote:
This is interesting, but you can bring that sort of approach to
some other language as well. Here is a simple approach to get
it done for Java:
http://java.dzone.com/articles/go-style-goroutines-java-and.
What is hard to implement
Support for green threads in std.concurrency is almost complete.
I should really just do the last bit of work. I imagine you could
try out the idea now though by using the messaging in vibe.d,
since every connection is a fiber.
On 2/4/14, 10:05 AM, Sean Kelly wrote:
Support for green threads in std.concurrency is almost complete. I
should really just do the last bit of work. I imagine you could try out
the idea now though by using the messaging in vibe.d, since every
connection is a fiber.
Did you express that work
On Tuesday, 4 February 2014 at 18:05:17 UTC, Sean Kelly wrote:
Support for green threads in std.concurrency is almost
complete. I should really just do the last bit of work. I
imagine you could try out the idea now though by using the
messaging in vibe.d, since every connection is a fiber.
On Tuesday, 4 February 2014 at 19:19:22 UTC, Dicebot wrote:
On Tuesday, 4 February 2014 at 18:05:17 UTC, Sean Kelly wrote:
Support for green threads in std.concurrency is almost
complete. I should really just do the last bit of work. I
imagine you could try out the idea now though by using the
Okay, just for fun, here are some results with the new scheduler.
I injected periodic yields into the code to simulate the
yielding that would happen automatically if the code was using
send and receive. First the code:
shared long count = 0;
shared static ~this() {
writefln(count =
It seems goroutine like process and channels are coming to C++:
https://github.com/ahorn/cpp-channel
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44
On Tuesday, 28 January 2014 at 17:25:35 UTC, Russel Winder wrote:
It seems goroutine like process and channels are coming to C++:
https://github.com/ahorn/cpp-channel
That's cool, but it is not going to be part of any standard? Is
it?
O.
33 matches
Mail list logo
