On Mar 23, 2012, at 11:17 AM, "Nathan M. Swan" wrote:
> On Friday, 23 March 2012 at 12:36:42 UTC, David Nadlinger wrote:
>> Are you trying to build std.concurrency from Git master against Phobos 2.058
>> or something like that?
>>
>> David
>
> I cloned from git://github.com/D-Programming-Langu
On 23.03.2012 22:17, Nathan M. Swan wrote:
On Friday, 23 March 2012 at 12:36:42 UTC, David Nadlinger wrote:
Are you trying to build std.concurrency from Git master against Phobos
2.058 or something like that?
David
I cloned from git://github.com/D-Programming-Language/phobos.git
NMS
replac
On Friday, 23 March 2012 at 12:36:42 UTC, David Nadlinger wrote:
Are you trying to build std.concurrency from Git master against
Phobos 2.058 or something like that?
David
I cloned from git://github.com/D-Programming-Language/phobos.git
NMS
On Friday, 23 March 2012 at 01:35:05 UTC, Nathan M. Swan wrote:
Used to work, and std.concurrency doesn't even use std.utf.
Not sure what's going on there.
Weird :(
Are you trying to build std.concurrency from Git master against
Phobos 2.058 or something like that?
David
On Friday, 23 March 2012 at 00:14:00 UTC, Sean Kelly wrote:
While sending messages like a bare string might be good for
example code, any real application is going to use structured
messages whose type is specific to what the message is for,
contains fields like sender Tid, etc. It seems like
On Mar 22, 2012, at 4:01 PM, Nathan M. Swan wrote:
> On Thursday, 22 March 2012 at 21:27:40 UTC, Sean Kelly wrote:
>> On Mar 22, 2012, at 12:06 PM, "Nathan M. Swan" wrote:
>>
>>> On Thursday, 22 March 2012 at 15:53:56 UTC, Sean Kelly wrote:
I can see adapting the API so that each thread has
On Thursday, 22 March 2012 at 21:27:40 UTC, Sean Kelly wrote:
On Mar 22, 2012, at 12:06 PM, "Nathan M. Swan"
wrote:
On Thursday, 22 March 2012 at 15:53:56 UTC, Sean Kelly wrote:
I can see adapting the API so that each thread has a default
message queue (keep in mind that we'll be adding inte
On Mar 22, 2012, at 12:06 PM, "Nathan M. Swan" wrote:
> On Thursday, 22 March 2012 at 15:53:56 UTC, Sean Kelly wrote:
>> I can see adapting the API so that each thread has a default message queue
>> (keep in mind that we'll be adding interprocess messaging at some point via
>> the same routines
On Thursday, 22 March 2012 at 15:53:56 UTC, Sean Kelly wrote:
I can see adapting the API so that each thread has a default
message queue (keep in mind that we'll be adding interprocess
messaging at some point via the same routines). I'm not yet
clear how the existence of alternate message queue
On Mar 22, 2012, at 8:49 AM, David Nadlinger wrote:
> On Thursday, 22 March 2012 at 00:30:51 UTC, Nathan M. Swan wrote:
>> As I posted a while back, the concept of a variant message queue is
>> wonderful and powerful, and the implementation is great. But the fact that
>> you can't declare "auto
Le 22/03/2012 16:50, David Nadlinger a écrit :
On Thursday, 22 March 2012 at 15:14:31 UTC, deadalnix wrote:
They will, even with different boxes.
Similarly succinct: How so?
They will because of synchronization. This cost will not be transparent.
Not that it is a bad idea, but it depends wh
On Thursday, 22 March 2012 at 15:14:31 UTC, deadalnix wrote:
They will, even with different boxes.
Similarly succinct: How so?
On Mar 21, 2012, at 9:12 PM, "Nathan M. Swan" wrote:
> On Wednesday, 21 March 2012 at 03:37:35 UTC, Nathan M. Swan wrote:
>> After playing around with making a library with uses threads, I realized it
>> would be nice if there could be multiple inter-thread mailboxes than just
>> one per thread
On Thursday, 22 March 2012 at 00:30:51 UTC, Nathan M. Swan wrote:
As I posted a while back, the concept of a variant message
queue is wonderful and powerful, and the implementation is
great. But the fact that you can't declare "auto mq = new
MessageQueue()" is a gaping whole in an otherwise A+
Le 21/03/2012 04:37, Nathan M. Swan a écrit :
After playing around with making a library with uses threads, I realized
it would be nice if there could be multiple inter-thread mailboxes than
just one per thread. That way, client code and third-party library code
don't interfere with each other.
Making such interface public would even allow to integrate D communication
mechanisms
between processes/machines, similar to what Akka allows.
"Nathan M. Swan" wrote in message
news:ladihiaieksszjodf...@forum.dlang.org...
On Wednesday, 21 March 2012 at 03:37:35 UTC, Nathan M. Swan wrote:
Aft
Am 22.03.2012 05:12, schrieb Nathan M. Swan:
On Wednesday, 21 March 2012 at 03:37:35 UTC, Nathan M. Swan wrote:
Each Tid contains a default MessageQueue accessible by property
messageQueue.
how is queued runned - another thread, or can i only communicate to the
tid-thread by using the queue? i
On Wednesday, 21 March 2012 at 03:37:35 UTC, Nathan M. Swan wrote:
After playing around with making a library with uses threads, I
realized it would be nice if there could be multiple
inter-thread mailboxes than just one per thread. That way,
client code and third-party library code don't inter
On Mar 21, 2012, at 5:30 PM, "Nathan M. Swan" wrote:
> On Wednesday, 21 March 2012 at 19:53:55 UTC, Sean Kelly wrote:
>> On Mar 20, 2012, at 8:37 PM, Nathan M. Swan wrote:
>>
>>> After playing around with making a library with uses threads, I realized it
>>> would be nice if there could be mult
On Wednesday, 21 March 2012 at 19:53:55 UTC, Sean Kelly wrote:
On Mar 20, 2012, at 8:37 PM, Nathan M. Swan wrote:
After playing around with making a library with uses threads,
I realized it would be nice if there could be multiple
inter-thread mailboxes than just one per thread. That way,
cli
On Mar 20, 2012, at 8:37 PM, Nathan M. Swan wrote:
> After playing around with making a library with uses threads, I realized it
> would be nice if there could be multiple inter-thread mailboxes than just one
> per thread. That way, client code and third-party library code don't
> interfere wit
After playing around with making a library with uses threads, I
realized it would be nice if there could be multiple inter-thread
mailboxes than just one per thread. That way, client code and
third-party library code don't interfere with each other.
So this is my proposal: that std.concurrency
22 matches
Mail list logo
