On Monday, 10 August 2015 at 22:21:18 UTC, 岩倉 澪 wrote:
On Saturday, 8 August 2015 at 06:24:30 UTC, sigod wrote:
Use negative value for `receiveTimeout`.
http://stackoverflow.com/q/31616339/944911
actually this no longer appears to be true?
Passing -1.msecs as the duration gives me an
On Monday, 10 August 2015 at 22:21:18 UTC, 岩倉 澪 wrote:
On Saturday, 8 August 2015 at 06:24:30 UTC, sigod wrote:
Use negative value for `receiveTimeout`.
http://stackoverflow.com/q/31616339/944911
actually this no longer appears to be true?
Passing -1.msecs as the duration gives me an
On Monday, 10 August 2015 at 22:21:18 UTC, 岩倉 澪 wrote:
On Saturday, 8 August 2015 at 06:24:30 UTC, sigod wrote:
Use negative value for `receiveTimeout`.
http://stackoverflow.com/q/31616339/944911
actually this no longer appears to be true?
Passing -1.msecs as the duration gives me an
On Monday, 10 August 2015 at 22:31:33 UTC, sigod wrote:
On Monday, 10 August 2015 at 22:21:18 UTC, 岩倉 澪 wrote:
[...]
It should be this line:
https://github.com/D-Programming-Language/phobos/blob/master/std/concurrency.d#L1910
[...]
This lines still there:
On Saturday, 8 August 2015 at 06:24:30 UTC, sigod wrote:
Use negative value for `receiveTimeout`.
http://stackoverflow.com/q/31616339/944911
actually this no longer appears to be true?
Passing -1.msecs as the duration gives me an assertion failure:
On Monday, 10 August 2015 at 22:50:15 UTC, sigod wrote:
On Monday, 10 August 2015 at 22:21:18 UTC, 岩倉 澪 wrote:
Took a look in phobos and it appears to be from this line:
https://github.com/D-Programming-Language/phobos/blob/master/std/concurrency.d#L1904
It looks like you're trying to use
There's indeed a good reason: Variant is a kitchen sink wrapper
and tries to declare questionable code for shared type, and
compiler catches that. Quite an impressive example of shared type
qualifier in action, even though Variant uses a lot of casting so
there's not a lot of type system at
On Sunday, 9 August 2015 at 21:06:10 UTC, anonymous wrote:
On Sunday, 9 August 2015 at 17:43:59 UTC, 岩倉 澪 wrote:
Afaict it is the best way to do what I'm trying to do, and
since the data is mutable and cast to immutable with
assumeUnique, casting it back to mutable shouldn't be a
problem.
On Sunday, 9 August 2015 at 17:43:59 UTC, 岩倉 澪 wrote:
Afaict it is the best way to do what I'm trying to do, and
since the data is mutable and cast to immutable with
assumeUnique, casting it back to mutable shouldn't be a
problem. Technically casting away immutable might be undefined
On Saturday, 8 August 2015 at 06:24:30 UTC, sigod wrote:
Use negative value for `receiveTimeout`.
http://stackoverflow.com/q/31616339/944911
On Saturday, 8 August 2015 at 13:34:24 UTC, Chris wrote:
Note aside: if you only import what you need (say `import
std.concurrency : receiveTimeout;
On Saturday, 8 August 2015 at 05:14:20 UTC, Meta wrote:
I'm not completely sure that it's bad in this case, but you
really shouldn't be casting away immutable. It's undefined
behaviour in D.
Afaict it is the best way to do what I'm trying to do, and since
the data is mutable and cast to
On Saturday, 8 August 2015 at 01:24:04 UTC, 岩倉 澪 wrote:
On Saturday, 8 August 2015 at 00:39:57 UTC, 岩倉 澪 wrote:
receiveTimeout(0.msecs,
(immutable Bar[] bar){ baz = cast(Bar[])bar;
});
Whoops, that should be:
receiveTimeout(0.msecs,
On Saturday, 8 August 2015 at 00:39:57 UTC, 岩倉 澪 wrote:
On Friday, 7 August 2015 at 22:13:35 UTC, 岩倉 澪 wrote:
message is local to the delegate that receiveTimeout takes.
I want to use message outside of the delegate in the
receiving thread. However, if you send an immutable value from
the
On Thursday, 6 August 2015 at 21:17:15 UTC, 岩倉 澪 wrote:
On Tuesday, 4 August 2015 at 08:35:10 UTC, Dicebot wrote:
// in real app use `receiveTimeout` to do useful stuff
until
// result message is received
auto output = receiveOnly!(immutable(Bar)[]);
New question: how would I
On Friday, 7 August 2015 at 15:55:33 UTC, Chris wrote:
Using a shared boolean is probably not the best way, I should
have said the most efficient and reliable way.
On Friday, 7 August 2015 at 15:55:33 UTC, Chris wrote:
To stop threads immediately, I've found that the best way is to
use a shared variable, typically a bool, that is changed only
in one place.
...
Unfortunately, sending an abort message to a thread as in
`send(thread, true)` takes too long.
On Friday, 7 August 2015 at 22:13:35 UTC, 岩倉 澪 wrote:
message is local to the delegate that receiveTimeout takes.
I want to use message outside of the delegate in the
receiving thread. However, if you send an immutable value from
the worker thread, afaict there would be no way to assign it to
On Saturday, 8 August 2015 at 00:39:57 UTC, 岩倉 澪 wrote:
receiveTimeout(0.msecs,
(immutable Bar[] bar){ baz = cast(Bar[])bar; });
Whoops, that should be:
receiveTimeout(0.msecs,
(immutable(Bar)[] bar){ baz = cast(Bar[])bar; });
On Saturday, 8 August 2015 at 00:39:57 UTC, 岩倉 澪 wrote:
Found the answer to this :)
http://forum.dlang.org/post/mailman.1706.1340318206.24740.digitalmars-d-le...@puremagic.com
I send the results from my worker thread with assumeUnique, and
then simply cast away immutable in the receiving
On Tuesday, 4 August 2015 at 08:35:10 UTC, Dicebot wrote:
// in real app use `receiveTimeout` to do useful stuff until
// result message is received
auto output = receiveOnly!(immutable(Bar)[]);
New question: how would I receive a immutable value with
receiveTimeout? I need the
On Tuesday, 4 August 2015 at 08:36:26 UTC, John Colvin wrote:
Do you mean this instead?
spawn(fooPtrToBarArr, foo, bar);
Yep, that was a typo when writing up the post!
Anyway, you need to use shared, not __gshared, then it should
work.
I have been wary of shared because of:
On Tuesday, 4 August 2015 at 10:29:57 UTC, 岩倉 澪 wrote:
On Tuesday, 4 August 2015 at 08:35:10 UTC, Dicebot wrote:
auto output = receiveOnly!(immutable(Bar)[]);
Won't message passing like this result in an expensive copy, or
does the cast to immutable via assumeUnique avoid that?
On Tue, 04 Aug 2015 10:29:55 +
岩倉 澪 mio.iwak...@gmail.com wrote:
On Tuesday, 4 August 2015 at 08:35:10 UTC, Dicebot wrote:
auto output = receiveOnly!(immutable(Bar)[]);
Won't message passing like this result in an expensive copy
No it will copy only struct containing length and
import std.concurrency;
import std.typecons : Unique;
import std.exception : assumeUnique;
struct Foo { }
struct Bar { }
void bar_generator (Tid ownerTid)
{
receive(
(shared(Foo)* input) {
auto output = new Bar[100];
// compute output ..
// ..
On Tuesday, 4 August 2015 at 08:03:54 UTC, 岩倉 澪 wrote:
Hi all, I'm a bit confused today (as usual, haha).
I have a pointer to a struct (let's call it Foo) allocated via
a C library.
I need to do some expensive computation with the Foo* to create
a Bar[], but I would like to do that
On 08/04/2015 01:03 AM, 岩倉 澪 wrote:
Hi all, I'm a bit confused today (as usual, haha).
I have a pointer to a struct (let's call it Foo) allocated via a C library.
I need to do some expensive computation with the Foo* to create a Bar[],
but I would like to do that computation in the background,
On Tuesday, 4 August 2015 at 10:37:39 UTC, Dicebot wrote:
std.concurrency does by-value message passing (in this case
just ptr+length), it never deep copies automatically
I assumed that it would deep copy (in the case of mutable data)
since the data being sent is thread-local (unless I am
On Tuesday, 4 August 2015 at 11:33:11 UTC, 岩倉 澪 wrote:
On Tuesday, 4 August 2015 at 10:37:39 UTC, Dicebot wrote:
std.concurrency does by-value message passing (in this case
just ptr+length), it never deep copies automatically
I assumed that it would deep copy (in the case of mutable data)
On Tuesday, 4 August 2015 at 08:35:10 UTC, Dicebot wrote:
auto output = receiveOnly!(immutable(Bar)[]);
Won't message passing like this result in an expensive copy, or
does the cast to immutable via assumeUnique avoid that?
On Tuesday, 4 August 2015 at 11:42:54 UTC, Dicebot wrote:
On Tuesday, 4 August 2015 at 11:33:11 UTC, 岩倉 澪 wrote:
On Tuesday, 4 August 2015 at 10:37:39 UTC, Dicebot wrote:
std.concurrency does by-value message passing (in this case
just ptr+length), it never deep copies automatically
I
30 matches
Mail list logo
