`.
What I am doing currently is populating the struct and casting to shared
when I push into a synchronized queue (no references to its data are
kept in the first thread). Is what I am doing wrong and can it be
achieved using message passing?
Yeah, build it like Ali says, and then cast in order
On 8/17/21 11:36 AM, JG wrote:
>>> Maybe message parsing isn't the
>>> correct solution?
I use message passing in many of my programs.
> After being populated it should be passed to
> the other thread and no references are kept.
Then you simply cast to-and-fr
this should have some
standard solution in D? I looked at std.concurrency and
thought that message passing could be used. However, the
problem is that I get the following error.
Error: static assert: "Aliases to mutable thread-local data
not allowed."
I am not sure how to solve this. May
and thought that message passing could be
used. However, the problem is that I get the following error.
Error: static assert: "Aliases to mutable thread-local data not allowed."
I am not sure how to solve this. Maybe message parsing isn't the
correct solution?
Is there some standar
at std.concurrency and thought
that message passing could be used. However, the problem is
that I get the following error.
Error: static assert: "Aliases to mutable thread-local data
not allowed."
I am not sure how to solve this.
The error tells you what you can't do. You can d
Hi
I have a program with two threads. One thread produces data that
is put in a queue
and then consumed by the other thread. I initially built a custom
queue to do this, but thought this should have some standard
solution in D? I looked at std.concurrency and thought that
message passing
On Monday, 11 September 2017 at 09:56:01 UTC, Jonas Mminnberg
1. receive() pattern matching -- what is common here, always
send (int, someData) where int is a value you compare to. Or
create dummy types that you can match on directly?
I would always create a new type and have it hold the
I am using the recommended message passing threading model for my
project, and it is not always clear how to do things in the best
way;
1. receive() pattern matching -- what is common here, always send
(int, someData) where int is a value you compare to. Or create
dummy types that you can
On 08/16/2016 07:21 AM, Kagamin via Digitalmars-d-learn wrote:
On Monday, 15 August 2016 at 01:53:33 UTC, Charles Hixson wrote:
If I modify the code to attempt to pass a Tid[] as a member of struct
Start I get:
/usr/include/dmd/phobos/std/concurrency.d(603): Error: static assert
"Aliases
On Monday, 15 August 2016 at 01:53:33 UTC, Charles Hixson wrote:
If I modify the code to attempt to pass a Tid[] as a member of
struct Start I get:
/usr/include/dmd/phobos/std/concurrency.d(603): Error: static
assert "Aliases to mutable thread-local data not allowed."
test.d(47):
I misunderstood the problem. The problem was that a dynamically sized
array cannot be sent as a message. So this works:
import std.concurrency;
import std.stdio;
import core.thread;
enum tidMax = 10;
struct Start { int tidCnt = 0; Tid[tidMax] tids; }
struct Msg { int
n't happen to be detected by the library.
On 08/14/2016 07:44 AM, Charles Hixson via Digitalmars-d-learn wrote:
This is an approach to n x n thread message passing. The idea is that
each thread should be able to pass messages to any other thread. The
only alternative I've come up with involves the m
On 08/14/2016 07:44 AM, Charles Hixson via Digitalmars-d-learn wrote:
This is an approach to n x n thread message passing. The idea is that
each thread should be able to pass messages to any other thread. The
only alternative I've come up with involves the main thread handling
each message
This is an approach to n x n thread message passing. The idea is that
each thread should be able to pass messages to any other thread. The
only alternative I've come up with involves the main thread handling
each message. Is that a better approach? Is there a better way to pass
lists
On Thursday, 30 July 2015 at 05:53:48 UTC, yawniek wrote:
On Wednesday, 29 July 2015 at 16:36:41 UTC, Atila Neves wrote:
LDC:
Cerealed: 970 ms, 482 μs, and 6 hnsecs
MsgPack: 896 ms, 591 μs, and 2 hnsecs
Not too shabby!
Atila
cool.
what are the advantages of cereald over msgpack?
AFAIK,
On Monday, 29 June 2015 at 10:22:10 UTC, Atila Neves wrote:
On Monday, 29 June 2015 at 08:45:15 UTC, Atila Neves wrote:
On Sunday, 28 June 2015 at 17:02:42 UTC, Nordlöw wrote:
On Friday, 26 June 2015 at 21:40:49 UTC, Atila Neves wrote:
I'd have to benchmark it against something, but I'm pretty
On Monday, 29 June 2015 at 13:59:37 UTC, Nordlöw wrote:
On Monday, 29 June 2015 at 10:22:10 UTC, Atila Neves wrote:
I guess I'm going to have benchmark this now... :)
What about doing a memory profiling using DMD fresh builtin
profiler of
http://dpaste.dzfl.pl/17b0ed9c0204
?
I'm guessing
On Wednesday, 29 July 2015 at 16:36:41 UTC, Atila Neves wrote:
LDC:
Cerealed: 970 ms, 482 μs, and 6 hnsecs
MsgPack: 896 ms, 591 μs, and 2 hnsecs
Not too shabby!
Atila
cool.
what are the advantages of cereald over msgpack?
can you stream in packets with cereald too?
cool thing about
On Friday, 26 June 2015 at 21:40:49 UTC, Atila Neves wrote:
I'd have to benchmark it against something, but I'm pretty sure
cerealed is fast.
Faster than msgpack?
On Monday, 29 June 2015 at 08:45:15 UTC, Atila Neves wrote:
On Sunday, 28 June 2015 at 17:02:42 UTC, Nordlöw wrote:
On Friday, 26 June 2015 at 21:40:49 UTC, Atila Neves wrote:
I'd have to benchmark it against something, but I'm pretty
sure cerealed is fast.
Faster than msgpack?
I guess I'm
On Sunday, 28 June 2015 at 17:02:42 UTC, Nordlöw wrote:
On Friday, 26 June 2015 at 21:40:49 UTC, Atila Neves wrote:
I'd have to benchmark it against something, but I'm pretty
sure cerealed is fast.
Faster than msgpack?
I guess I'm going to have benchmark this now... :)
Atila
On Monday, 29 June 2015 at 10:22:10 UTC, Atila Neves wrote:
I guess I'm going to have benchmark this now... :)
What about doing a memory profiling using DMD fresh builtin
profiler of
http://dpaste.dzfl.pl/17b0ed9c0204
?
I'm guessing the GC might give misguiding results as your
testStruct
On Friday, 26 June 2015 at 11:13:11 UTC, Per Nordlöw wrote:
On Friday, 26 June 2015 at 10:23:26 UTC, Laeeth Isharc wrote:
On Friday, 26 June 2015 at 09:06:18 UTC, Per Nordlöw wrote:
On Thursday, 25 June 2015 at 23:23:01 UTC, Laeeth Isharc
wrote:
not sure if this is quite what you are looking
On Friday, 26 June 2015 at 12:31:04 UTC, Dicebot wrote:
std.concurrency was supposed to be able to handle that by
design but it is impossible to do without any sort of standard
serialization utility in Phobos (and, ideally, very fast binary
serialization utility)
I'd have to benchmark it
On Thursday, 25 June 2015 at 23:23:01 UTC, Laeeth Isharc wrote:
not sure if this is quite what you are looking for, or if the
performance overhead is acceptable but have you looked at
msgpack to go on top of a lower level pipe ?
Why is a lower-level pipe needed, when we have pipe in
On Friday, 26 June 2015 at 09:06:18 UTC, Per Nordlöw wrote:
On Thursday, 25 June 2015 at 23:23:01 UTC, Laeeth Isharc wrote:
not sure if this is quite what you are looking for, or if the
performance overhead is acceptable but have you looked at
msgpack to go on top of a lower level pipe ?
Why
std.concurrency was supposed to be able to handle that by design
but it is impossible to do without any sort of standard
serialization utility in Phobos (and, ideally, very fast binary
serialization utility)
On Friday, 26 June 2015 at 10:23:26 UTC, Laeeth Isharc wrote:
On Friday, 26 June 2015 at 09:06:18 UTC, Per Nordlöw wrote:
On Thursday, 25 June 2015 at 23:23:01 UTC, Laeeth Isharc wrote:
not sure if this is quite what you are looking for, or if the
performance overhead is acceptable but have
On Thursday, 25 June 2015 at 14:04:23 UTC, Per Nordlöw wrote:
Is there an alternative to
http://dlang.org/phobos/std_process.html#.pipe
that can be used to do _typed_ _message_ _passing_ between two
D processes with the same convenience as `send` and `receive` in
std.concurrency
?
Either
Is there an alternative to
http://dlang.org/phobos/std_process.html#.pipe
that can be used to do _typed_ _message_ _passing_ between two D
processes with the same convenience as `send` and `receive` in
std.concurrency
?
Either in Phobos or in a third party library?
On Thursday, 25 June 2015 at 14:04:23 UTC, Per Nordlöw wrote:
Is there an alternative to
http://dlang.org/phobos/std_process.html#.pipe
that can be used to do _typed_ _message_ _passing_ between two
D processes with the same convenience as `send` and `receive` in
std.concurrency
?
Either
I'm trying to impose limits upon myself to, well, learn.
Currently I'm exploring ways to avoid allocations -- but my
program is running in three threads with considerable amounts of
message passing between them.
Unless I'm misinterpreting my callgraph,
std.concurrency.MessageBox contains
std.allocator has one.
Andrei
Great to hear!
What's the review status on std.allocator?
I believe a lock-free solution would surely outperform a
mutex-lock-based solution for many small messages. Have anybody
benchmarked the overhead of D's Mutex lock/unlocks?
What's the best solution to communicate between threads in D
today if I care about
1. Security Correctness?
2. Performance?
and are these mutually exclusive?
Does Phobos or other library contain lockfree queues?
From what I can see std.concurrent.MessageBox requires
Mutex-locking. Is this
On Tuesday, 18 February 2014 at 21:05:38 UTC, Nordlöw wrote:
What's the best solution to communicate between threads in D
today if I care about
1. Security Correctness?
2. Performance?
and are these mutually exclusive?
Does Phobos or other library contain lockfree queues?
From what I can
patterns
etc. (cache misses can hurt you more than lock overheads ever
will)
Most benchmarks that show amazing lock-free performance scaling
deal with pathological cases. A lot of real-world code can be
plenty fast (or even faster) with message-passing or (sometimes
even) locks.
Security
On Tuesday, 18 February 2014 at 21:21:54 UTC, deadalnix wrote:
On Tuesday, 18 February 2014 at 21:05:38 UTC, Nordlöw wrote:
What's the best solution to communicate between threads in D
today if I care about
1. Security Correctness?
2. Performance?
and are these mutually exclusive?
Does
I have no experience in writing threadlocking queues.
I of course mean lock-free queues.
/Per
On Tuesday, 18 February 2014 at 21:37:09 UTC, Nordlöw wrote:
On Tuesday, 18 February 2014 at 21:21:54 UTC, deadalnix wrote:
On Tuesday, 18 February 2014 at 21:05:38 UTC, Nordlöw wrote:
What's the best solution to communicate between threads in D
today if I care about
1. Security
On 2/19/14, 12:20 AM, Nordlöw wrote:
I have no experience in writing threadlocking queues.
I of course mean lock-free queues.
/Per
std.allocator has one.
Andrei
On Tuesday, 18 February 2014 at 23:45:37 UTC, Andrei Alexandrescu
wrote:
On 2/19/14, 12:20 AM, Nordlöw wrote:
I have no experience in writing threadlocking queues.
I of course mean lock-free queues.
/Per
std.allocator has one.
Andrei
I'd say upcoming std.allocator will have one. It's
On Tuesday, 18 February 2014 at 21:37:09 UTC, Nordlöw wrote:
On Tuesday, 18 February 2014 at 21:21:54 UTC, deadalnix wrote:
On Tuesday, 18 February 2014 at 21:05:38 UTC, Nordlöw wrote:
What's the best solution to communicate between threads in D
today if I care about
1. Security
Hey, I'm handling concurrency with message passing, previously
with D's concurrency, now with Vibe-d, which I assume works the
same way.
My app is a chat server, and when a connection is opened to a
client, I store the Tid of the thread (or fibre?) handling
sending messages out to the client
A small example:
while (true) {
receive(
(Tid tid, AddTid _) {some code}
(Tid tid, RemoveTid _) {some other code}
(string s) {broadcast stuff}
)
}
struct AddTid {}
struct RemoveTid {}
On Wednesday, 29 January 2014 at 21:50:28 UTC, Casper Færgemand
wrote:
A small example:
while (true) {
receive(
(Tid tid, AddTid _) {some code}
(Tid tid, RemoveTid _) {some other code}
(string s) {broadcast stuff}
)
}
struct AddTid {}
struct RemoveTid {}
From where I sit
I was trying to do a simple program to test message passing.
Basically, I have 1 owner, and 2 slave threads.
I'm facing two problems:
1 ) First, I want the slaves to be informed of when the master
dies in an abnormal way.
TDPL suggest OwnerFailed, but apparently, the out of band
exception
On 22.1.2013 11:08, monarch_dodra wrote:
I was trying to do a simple program to test message passing.
Basically, I have 1 owner, and 2 slave threads.
I'm facing two problems:
1 ) First, I want the slaves to be informed of when the master dies in
an abnormal way.
TDPL suggest
On 01/22/2013 04:26 AM, Martin Drasar wrote:
On 22.1.2013 11:08, monarch_dodra wrote:
I was trying to do a simple program to test message passing.
wouldn't this help you?
http://dlang.org/phobos/std_concurrency.html#.spawnLinked
The following chapter may be helpful as well:
http
message passing.
wouldn't this help you?
http://dlang.org/phobos/std_concurrency.html#.spawnLinked
The following chapter may be helpful as well:
http://ddili.org/ders/d.en/concurrency.html
Especially the following sections:
- Exceptions during the execution of the worker
- Detecting thread
On 01/22/2013 09:04 AM, monarch_dodra wrote:
I'm getting some errors with this program:
I can not reproduce this problem on Linux. Not with -m64 nor with -m32.
I don't think the following is necessary but it has been a workaround
for me in the past:
import core.thread;
void main(string[]
I wonder how much it helps to just optimize the GC a little. How much
does the performance gap close when you use DMD 2.058 beta instead of
2.057? This upcoming release has several new garbage collector
optimizations. If the GC is the bottleneck, then it's not surprising
Is there a way
On 2012-02-10 14:54, Oliver Plow wrote:
I wonder how much it helps to just optimize the GC a little. How much
does the performance gap close when you use DMD 2.058 beta instead of
2.057? This upcoming release has several new garbage collector
optimizations. If the GC is the bottleneck, then
Le 09/02/2012 20:57, Martin Nowak a écrit :
On Thu, 09 Feb 2012 16:44:46 +0100, Sean Kelly s...@invisibleduck.org
wrote:
So a queue per message type? How would ordering be preserved? Also,
how would this work for interprocess messaging? An array-based queue
is an option however (though it
On 02/10/12 14:54, Oliver Plow wrote:
I wonder how much it helps to just optimize the GC a little. How much
does the performance gap close when you use DMD 2.058 beta instead of
2.057? This upcoming release has several new garbage collector
optimizations. If the GC is the bottleneck, then
GC.disable and GC.reserve are applicable. I tested with these and they did help
but not a ton.
On Feb 10, 2012, at 5:54 AM, Oliver Plow saxo...@gmx.de wrote:
I wonder how much it helps to just optimize the GC a little. How much
does the performance gap close when you use DMD 2.058 beta
On Fri, 10 Feb 2012 15:07:41 +0100, deadalnix deadal...@gmail.com wrote:
Le 09/02/2012 20:57, Martin Nowak a écrit :
On Thu, 09 Feb 2012 16:44:46 +0100, Sean Kelly s...@invisibleduck.org
wrote:
So a queue per message type? How would ordering be preserved? Also,
how would this work for
On Feb 9, 2012, at 2:17 PM, Sean Kelly wrote:
On Feb 9, 2012, at 11:57 AM, Martin Nowak wrote:
I didn't yet got around to polish my lock-free SList/DList implementations,
but mutexes should only become a problem with high contention when you need
to block.
You'd also would need some kind
Hello,
I'm a complete newbie in D and trying to compare with Java. I
implemented a simple test for measuring the throughput in message
passing between threads. I see that Java can pass about 4mil
messages/sec while D only achieves 1mil/sec. I thought that D should
be faster.
The messages
Am 09.02.2012, 10:06 Uhr, schrieb Nicolae Mihalache xproma...@gmail.com:
Hello,
I'm a complete newbie in D and trying to compare with Java. I
implemented a simple test for measuring the throughput in message
passing between threads. I see that Java can pass about 4mil
messages/sec while D
Nicolae Mihalache xproma...@gmail.com wrote:
Hello,
I'm a complete newbie in D and trying to compare with Java. I
implemented a simple test for measuring the throughput in message
passing between threads. I see that Java can pass about 4mil
messages/sec while D only achieves 1mil/sec. I
wrote:
Nicolae Mihalache xproma...@gmail.com wrote:
Hello,
I'm a complete newbie in D and trying to compare with Java. I
implemented a simple test for measuring the throughput in message
passing between threads. I see that Java can pass about 4mil
messages/sec while D only achieves 1mil/sec. I
Sorry, my mistake. It's strange to have different 'n', but you measure speed
as 1000*n/time, so it's doesn't matter if n is 10 times bigger.
Generally, D's message passing is implemented in quite easy-to-use
way, but far from being fast.
I dislike the Variant structure, because it adds a huge overhead. I'd
rather have a templated message passing system with type-safe message
queue, so no Variant is necessary.
In specific cases Messages
.
On Feb 9, 2012, at 6:10 AM, Gor Gyolchanyan
gor.f.gyolchan...@gmail.com wrote:
Generally, D's message passing is implemented in quite
easy-to-use
way, but far from being fast.
I dislike the Variant structure, because it adds a huge
overhead. I'd
rather have a templated message passing system
old memory blocks vs. just expecting the
allocator to be fast.
On Feb 9, 2012, at 6:10 AM, Gor Gyolchanyan gor.f.gyolchan...@gmail.com
wrote:
Generally, D's message passing is implemented in quite easy-to-use
way, but far from being fast.
I dislike the Variant structure, because it adds
On 2/9/12 6:10 AM, Gor Gyolchanyan wrote:
Generally, D's message passing is implemented in quite easy-to-use
way, but far from being fast.
I dislike the Variant structure, because it adds a huge overhead. I'd
rather have a templated message passing system with type-safe message
queue, so
Am 09.02.2012, 17:22 Uhr, schrieb dsimcha dsim...@yahoo.com:
I wonder how much it helps to just optimize the GC a little. How much
does the performance gap close when you use DMD 2.058 beta instead of
2.057? This upcoming release has several new garbage collector
optimizations. If the
Am 09.02.2012, 18:35 Uhr, schrieb Andrei Alexandrescu
seewebsiteforem...@erdani.org:
On 2/9/12 6:10 AM, Gor Gyolchanyan wrote:
Generally, D's message passing is implemented in quite easy-to-use
way, but far from being fast.
I dislike the Variant structure, because it adds a huge overhead
On Feb 9, 2012, at 10:14 AM, Marco Leise wrote:
Am 09.02.2012, 17:22 Uhr, schrieb dsimcha dsim...@yahoo.com:
I wonder how much it helps to just optimize the GC a little. How much does
the performance gap close when you use DMD 2.058 beta instead of 2.057?
This upcoming release has
On 2/9/12 10:31 AM, Marco Leise wrote:
Am 09.02.2012, 18:35 Uhr, schrieb Andrei Alexandrescu
seewebsiteforem...@erdani.org:
On 2/9/12 6:10 AM, Gor Gyolchanyan wrote:
Generally, D's message passing is implemented in quite easy-to-use
way, but far from being fast.
I dislike the Variant
On 02/09/2012 08:27 PM, Sean Kelly wrote:
On Feb 9, 2012, at 10:14 AM, Marco Leise wrote:
Am 09.02.2012, 17:22 Uhr, schrieb dsimchadsim...@yahoo.com:
I wonder how much it helps to just optimize the GC a little. How much does the
performance gap close when you use DMD 2.058 beta instead of
Am 09.02.2012, 20:35 Uhr, schrieb Andrei Alexandrescu
seewebsiteforem...@erdani.org:
If we're doing one allocation per
message passed, that might explain the 4x performance difference (I
have no trouble figuring Java's allocator is this much faster than
D's).
Andrei
Well, what does +1
Marco Leise:
Sean found another possible allocation in the other
branch of this discussion.
Maybe this is able to help Sean and similar situations:
http://d.puremagic.com/issues/show_bug.cgi?id=5070
Bye,
bearophile
On Thu, 09 Feb 2012 16:44:46 +0100, Sean Kelly s...@invisibleduck.org
wrote:
So a queue per message type? How would ordering be preserved? Also, how
would this work for interprocess messaging? An array-based queue is an
option however (though it would mean memmoves on receive), as are
On 2/9/12 11:49 AM, Marco Leise wrote:
Am 09.02.2012, 20:35 Uhr, schrieb Andrei Alexandrescu
seewebsiteforem...@erdani.org:
If we're doing one allocation per
message passed, that might explain the 4x performance difference (I
have no trouble figuring Java's allocator is this much faster than
On Feb 9, 2012, at 10:31 AM, Marco Leise wrote:
Am 09.02.2012, 18:35 Uhr, schrieb Andrei Alexandrescu
seewebsiteforem...@erdani.org:
On 2/9/12 6:10 AM, Gor Gyolchanyan wrote:
Generally, D's message passing is implemented in quite easy-to-use
way, but far from being fast.
I dislike
On Feb 9, 2012, at 11:53 AM, bearophile wrote:
Marco Leise:
Sean found another possible allocation in the other
branch of this discussion.
Maybe this is able to help Sean and similar situations:
http://d.puremagic.com/issues/show_bug.cgi?id=5070
This would be handy. I don't always
On Feb 9, 2012, at 11:57 AM, Martin Nowak wrote:
On Thu, 09 Feb 2012 16:44:46 +0100, Sean Kelly s...@invisibleduck.org wrote:
So a queue per message type? How would ordering be preserved? Also, how
would this work for interprocess messaging? An array-based queue is an
option however
issues.
Regards, Oliver
Original-Nachricht
Datum: Thu, 9 Feb 2012 10:06:40 +0100
Von: Nicolae Mihalache xproma...@gmail.com
An: digitalmars-d@puremagic.com
Betreff: Message passing between threads: Java 4 times faster than D
Hello,
I'm a complete newbie in D and trying
shared slist
for the node free-list, though I couldn't weigh the chance of cache misses from
using old memory blocks vs. just expecting the allocator to be fast.
On Feb 9, 2012, at 6:10 AM, Gor Gyolchanyangor.f.gyolchan...@gmail.com wrote:
Generally, D's message passing is implemented in quite
On Feb 9, 2012, at 2:17 PM, Sean Kelly wrote:
Best first order optimization would be to allocate the list node
deterministically.
Neat idea. I think I can make that change fairly trivially.
$ time abc
real0m0.556s
user0m0.555s
sys 0m0.001s
So another 100ms improvement.
On 2/9/12 11:17 PM, Sean Kelly wrote:
On Feb 9, 2012, at 11:57 AM, Martin Nowak wrote:
I didn't yet got around to polish my lock-free SList/DList implementations,
but mutexes should only become a problem with high contention when you need to
block.
You'd also would need some kind of blocking
On Thu, Feb 9, 2012 at 3:06 AM, Nicolae Mihalache xproma...@gmail.com wrote:
Hello,
I'm a complete newbie in D and trying to compare with Java. I
implemented a simple test for measuring the throughput in message
passing between threads. I see that Java can pass about 4mil
messages/sec while
I recently completed a message passing library in D that lets the
messages be passed between actors that don't necessarily correspond to
threads (as std.concurrency requires). I'll see how it does on your
benchmark.
Sounds quite interesting. You created some kind of thread pool for your
message passing API is reasonable and
safe: Its concurrency model is the main selling point of erlang.
http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang
Oh come on.. It's niche, unfamiliar to most people, and we're talking about
name and argument list
. It is
successful in its niche. Copying its message passing API is reasonable and
safe: Its concurrency model is the main selling point of erlang.
http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang
Oh come on.. It's niche, unfamiliar to most people, and we're
by erlang on a daily basis. It
is successful in its niche. Copying its message passing API is reasonable
and safe: Its concurrency model is the main selling point of erlang.
http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang
Oh come on.. It's niche
On 01/26/2012 10:19 PM, Manu wrote:
C# has generics. Not quite like D templates, more like C++, but still...
C# generics and C++/D templates are *very* different things. C# generics
make code type check (and duplicate static variables), templates
duplicate the whole code. C# does not have
On Jan 26, 2012, at 1:19 PM, Manu wrote:
On 26 January 2012 22:07, Sean Kelly s...@invisibleduck.org wrote:
What I like about receiveOnly is that the name itself suggests that
anything other than the specified type is not expected, and so some measure
will probably be taken.
Again,
On 23 January 2012 02:00, Timon Gehr timon.g...@gmx.ch wrote:
Erlang *has* been used in multiple large projects and it is likely that
you make use of some service that is powered by erlang on a daily basis. It
is successful in its niche. Copying its message passing API is reasonable
and safe
On 01/25/2012 11:49 AM, Manu wrote:
...
My argument is that you shouldn't have to read the docs AT ALL to access
basic functionality. I say how do I create a worker thread?, and
someone in the office answers use std.concurrency, I type
std.concurrency and press '.', everything I care about
On 23 January 2012 01:49, Sean Kelly s...@invisibleduck.org wrote:
The names as they exist match what's in TDPL, so they're somewhat set in
stone.
Ah, I see. That makes it considerably harder to go back on then :)
Am 22.01.2012, 01:42 Uhr, schrieb Sean Kelly s...@invisibleduck.org:
On Jan 21, 2012, at 10:35 AM, Manu turkey...@gmail.com wrote:
On 21 January 2012 18:09, Sean Kelly s...@invisibleduck.org
Seriously? I usually turn that feature off if I use an IDE that has
it. Large projects aren't an
On 2012-01-21 19:35, Manu wrote:
On 21 January 2012 18:09, Sean Kelly s...@invisibleduck.org
mailto:s...@invisibleduck.org wrote:
I suggest checking out Erlang messaging, as it's the basis for this
design. Maybe then things will be a bit clearer.
Are you suggesting that erlang is a
On 22 January 2012 15:18, Jacob Carlborg d...@me.com wrote:
On 2012-01-21 19:35, Manu wrote:
On 21 January 2012 18:09, Sean Kelly s...@invisibleduck.org
mailto:s...@invisibleduck.org** wrote:
I suggest checking out Erlang messaging, as it's the basis for this
design. Maybe then
The popularity of a language has no bearing on the quality of one of its
features. Are there other message passing schemes you prefer?
Sent from my iPhone
On Jan 22, 2012, at 5:53 AM, Manu turkey...@gmail.com wrote:
On 22 January 2012 15:18, Jacob Carlborg d...@me.com wrote:
On 2012-01-21 19
On 22 January 2012 18:42, Sean Kelly s...@invisibleduck.org wrote:
The popularity of a language has no bearing on the quality of one of its
features. Are there other message passing schemes you prefer?
As said in the original post, I think receiveOnly() is the most intuitive
API. I just think
On 1/22/12 3:18 PM, Manu wrote:
On 22 January 2012 18:42, Sean Kelly s...@invisibleduck.org
mailto:s...@invisibleduck.org wrote:
The popularity of a language has no bearing on the quality of one of
its features. Are there other message passing schemes you prefer?
As said
On Thursday, 19 January 2012 at 22:36:17 UTC, Sean Kelly wrote:
Thanks :-) If you have ideas on how it could be improved,
please let me know.
I don't know whether it's good or not, but in my system based on
std.concurrency:
* i had to add in-thread messaging in case when there will be
more
of
its features. Are there other message passing schemes you prefer?
As said in the original post, I think receiveOnly() is the most
intuitive API. I just think that one should be named receive(), and
perhaps receive() may be renamed receiveMulti(). Surely that would be
more intuitive to more
1 - 100 of 176 matches
Mail list logo
