On 04/09/2016 07:45 AM, Nordlöw wrote:
> On Friday, 8 April 2016 at 10:51:49 UTC, Nordlöw wrote:
> AFAICT, it is not clear what are the limitations of the current
> std.concurrency and, from what. An illustrating example on task-based
> parallellism (such as the ones in jin.go) should partly
On 04/08/2016 02:42 PM, Dicebot wrote:
>> Thanks Dicebot. I don't think the included
>> std.concurrency.FiberScheduler has support for message passing because
>> FiberScheduler.spawn does not return a Tid. If so, I don't see how
>> it's possible to send messages between fibers.
>>
>> Ali
>
>
On Friday, 8 April 2016 at 10:51:49 UTC, Nordlöw wrote:
Are there any plans to unite
AFAICT, it is not clear what are the limitations of the current
std.concurrency and, from what. An illustrating example on
task-based parallellism (such as the ones in jin.go) should
partly alleviate this
On Friday, 8 April 2016 at 20:25:11 UTC, Ali Çehreli wrote:
On 04/08/2016 01:16 PM, Dicebot wrote:
On Friday, 8 April 2016 at 19:46:17 UTC, tcak wrote:
On Friday, 8 April 2016 at 15:33:46 UTC, Dicebot wrote:
On Friday, 8 April 2016 at 14:08:39 UTC, Nordlöw wrote:
So a TId can represent
On 04/08/2016 01:16 PM, Dicebot wrote:
On Friday, 8 April 2016 at 19:46:17 UTC, tcak wrote:
On Friday, 8 April 2016 at 15:33:46 UTC, Dicebot wrote:
On Friday, 8 April 2016 at 14:08:39 UTC, Nordlöw wrote:
So a TId can represent either a thread or a fiber?
AFAIR, yes (I haven't used
On Friday, 8 April 2016 at 19:46:17 UTC, tcak wrote:
On Friday, 8 April 2016 at 15:33:46 UTC, Dicebot wrote:
On Friday, 8 April 2016 at 14:08:39 UTC, Nordlöw wrote:
So a TId can represent either a thread or a fiber?
AFAIR, yes (I haven't used std.concurrency in a long while,
telling all
On Friday, 8 April 2016 at 15:33:46 UTC, Dicebot wrote:
On Friday, 8 April 2016 at 14:08:39 UTC, Nordlöw wrote:
So a TId can represent either a thread or a fiber?
AFAIR, yes (I haven't used std.concurrency in a long while,
telling all from memory only).
yes what? Thread or Fiber.
---
On Friday, 8 April 2016 at 14:08:39 UTC, Nordlöw wrote:
So a TId can represent either a thread or a fiber?
It represents a "logical thread", which currently consists of
coroutines or OS threads but could theoretically be extended to,
say, other processes or even other machines.
On Friday, 8 April 2016 at 14:08:39 UTC, Nordlöw wrote:
So a TId can represent either a thread or a fiber?
AFAIR, yes (I haven't used std.concurrency in a long while,
telling all from memory only).
On Friday, 8 April 2016 at 13:15:07 UTC, Dicebot wrote:
On Friday, 8 April 2016 at 11:18:11 UTC, Nordlöw wrote:
On Friday, 8 April 2016 at 11:01:21 UTC, Dicebot wrote:
Doesn't std.concurrency support both right now? I remember
seeing PR that adds message box support to fibers ages ago.
See
On Friday, 8 April 2016 at 11:18:11 UTC, Nordlöw wrote:
On Friday, 8 April 2016 at 11:01:21 UTC, Dicebot wrote:
Doesn't std.concurrency support both right now? I remember
seeing PR that adds message box support to fibers ages ago.
See https://issues.dlang.org/show_bug.cgi?id=12090 and
On Friday, 8 April 2016 at 11:01:21 UTC, Dicebot wrote:
Doesn't std.concurrency support both right now? I remember
seeing PR that adds message box support to fibers ages ago.
What progress has been since post:
http://forum.dlang.org/post/k4jsef$26h6$1...@digitalmars.com
On Friday, 8 April 2016 at 11:01:21 UTC, Dicebot wrote:
Doesn't std.concurrency support both right now? I remember
seeing PR that adds message box support to fibers ages ago.
1. What functions provide message box communication?
2. But Fibers cannot currently be moved between threads right?
On Friday, 8 April 2016 at 10:51:49 UTC, Nordlöw wrote:
Are there any plans to unite
fiber-to-fiber communication
with
thread-to-thread communication
in Phobos?
Does vibe.d give any solutions here?
Doesn't std.concurrency support both right now? I remember seeing
PR that adds message box
Are there any plans to unite
fiber-to-fiber communication
with
thread-to-thread communication
in Phobos?
Does vibe.d give any solutions here?
On Thursday, 6 August 2015 at 08:40:58 UTC, Kagamin wrote:
}
AFAIK, boost does it by integrating support for interruption
into various functions, so IO, waits and locks reply to
interrupt requests appropriately. You can do something similar.
I understand the philosophy behind
On Tuesday, 4 August 2015 at 15:19:51 UTC, Chris wrote:
foreach (ref i; 0..10)
{
writefln(%d.\tDoing something with input %s, i+1,
input);
Thread.sleep(500.msecs);
}
AFAIK, boost does it by integrating support for interruption into
various
On Tuesday, 4 August 2015 at 15:19:51 UTC, Chris wrote:
I want to stop (and abort) the worker as soon as new input
arrives. However, while executing the function that contains
the foreach-loop the worker thread doesn't listen, because it's
busy, of course.
I think this is a matter of
On Tuesday, 4 August 2015 at 18:15:08 UTC, Ali Çehreli wrote:
On 08/04/2015 09:19 AM, Dicebot wrote:
receiveTimeout
I think the problem here is that the worker is busy, not even
able to call that.
This sounds like sending a signal to the specific thread (with
pthread_kill()) but I don't
On Wednesday, 5 August 2015 at 14:31:20 UTC, Marc Schütz wrote:
Maybe we can lift this restriction if we know that the thread's
main function is pure and takes no references to mutable data,
because then it can by definition never mess up the program's
state.
That'd be a pretty useless
On Wednesday, 5 August 2015 at 11:23:28 UTC, Chris wrote:
The problem is that it works up to a certain extent with
receiveTimeout. However, if the input arrives in very short
intervals, all the solutions I've come up with so far
(including data sharing) fail sooner or later. New threads are
On Wednesday, 5 August 2015 at 14:34:42 UTC, Alex Parrill wrote:
On Wednesday, 5 August 2015 at 14:31:20 UTC, Marc Schütz wrote:
Maybe we can lift this restriction if we know that the
thread's main function is pure and takes no references to
mutable data, because then it can by definition
On Wednesday, 5 August 2015 at 14:31:20 UTC, Marc Schütz wrote:
It was a conscious decision not to provide a kill method for
threads, because it is impossible to guarantee that your
program is still consistent afterwards.
What about the situation where we want to kill worker threads off
when
Is there a good way to stop work-intensive threads via thread
communication (instead of using a shared variable)? The example
below is very basic and naive and only meant to exemplify the
basic problem.
I want to stop (and abort) the worker as soon as new input
arrives. However, while
receiveTimeout
On 08/04/2015 09:19 AM, Dicebot wrote:
receiveTimeout
I think the problem here is that the worker is busy, not even able to
call that.
This sounds like sending a signal to the specific thread (with
pthread_kill()) but I don't know the details of it nor whether Phobos
supports it.
Ali
I'm building a program which I intend to have many threads that can each send
messages to (and receive messages from) each other. The obvious way to do
this would be to have a shared array of Tids, but this seems to not work. I'm
continually fighting the system to get it to compile, and this
On Saturday, 17 May 2014 at 18:43:25 UTC, Charles Hixson via
Digitalmars-d-learn wrote:
I'm building a program which I intend to have many threads that
can each send
messages to (and receive messages from) each other. The
obvious way to do
this would be to have a shared array of Tids, but this
On 05/17/2014 12:33 PM, John Colvin wrote:
On Saturday, 17 May 2014 at 18:43:25 UTC, Charles Hixson via
Digitalmars-d-learn wrote:
I'm building a program which I intend to have many threads that can
each send
messages to (and receive messages from) each other. The obvious way
to do
this would
On Saturday, May 17, 2014 12:59:22 PM Ali Çehreli via Digitalmars-d-learn
wrote:
On 05/17/2014 12:33 PM, John Colvin wrote:
On Saturday, 17 May 2014 at 18:43:25 UTC, Charles Hixson via
Digitalmars-d-learn wrote:
I'm building a program which I intend to have many threads that can
each
30 matches
Mail list logo
