Is the following snippet a bug?

---
import core.thread;
import std.stdio, std.concurrency;

void foo(Tid tid) {
    send(tid, true);
}

void main() {
    auto fooTid = spawn(&foo, thisTid);
    auto receiveInt = receiveTimeout(dur!"seconds"(10), (int isInt) {
        writeln("I should not be here");
    });
}
// output: "I should not be here"
---

If not, is there some way I could achieve "receiveOnlyTimeout!(int)(dur, fun);" ?

Thanks,
Josh

On Thursday, 18 October 2012 at 06:30:08 UTC, Joshua Niehus wrote:
> Is the following snippet a bug?
>
> ---
> import core.thread;
> import std.stdio, std.concurrency;
>
> void foo(Tid tid) {
>     send(tid, true);
> }
>
> void main() {
>     auto fooTid = spawn(&foo, thisTid);
>     auto receiveInt = receiveTimeout(dur!"seconds"(10), (int isInt) {
>         writeln("I should not be here");
>     });
> }
> // output: "I should not be here"
> ---
>
> If not, is there some way I could achieve "receiveOnlyTimeout!(int)(dur, fun);" ?
>
> Thanks,
> Josh

I can't see the bug? The receiver accepts a bool as an int, same way a normal function does. The timeout is long enough that foo gets a chance to send.  If you want to stop the int receiver getting a bool, you could add another receiver with (bool) { // do nothing } or whatever before the (int) one, which will be a better match for the send.

On 10/17/2012 11:29 PM, Joshua Niehus wrote:
> Is the following snippet a bug?
>
> ---
> import core.thread;
> import std.stdio, std.concurrency;
>
> void foo(Tid tid) {
> send(tid, true);
> }
>
> void main() {
> auto fooTid = spawn(&foo, thisTid);
> auto receiveInt = receiveTimeout(dur!"seconds"(10), (int isInt) {
> writeln("I should not be here");
> });
> }
> // output: "I should not be here"
> ---
>
> If not, is there some way I could achieve "receiveOnlyTimeout!(int)(dur,
> fun);" ?
>
> Thanks,
> Josh

I am not sure whether it is supposed to be, but the function must be a module-level function; so define it outside of main.

When I did that, there was segmentation fault if I used thread priority.

Workaround:

1) Take function out of main

2) Do not specify thread priority

Created bug report:

  http://d.puremagic.com/issues/show_bug.cgi?id=8849

Ali

Sorry, wrong thread. :(

Ali

On Oct 17, 2012, at 11:29 PM, Joshua Niehus <jm.niehus@gmail.com> wrote:

> Is the following snippet a bug?
> 
> ---
> import core.thread;
> import std.stdio, std.concurrency;
> 
> void foo(Tid tid) {
>    send(tid, true);
> }
> 
> void main() {
>    auto fooTid = spawn(&foo, thisTid);
>    auto receiveInt = receiveTimeout(dur!"seconds"(10), (int isInt) {
>        writeln("I should not be here");
>    });

spawn() shouldn't allow you to spawn a delegate.  Last I checked (which was admittedly a while ago), there were some compiler issues around actually verifying the function signature sent to spawn() though.

On Thursday, 18 October 2012 at 18:31:09 UTC, Sean Kelly wrote:
> On Oct 17, 2012, at 11:29 PM, Joshua Niehus
>> void foo(Tid tid) {
>>    send(tid, true);
>> }
/* snip */
> spawn() shouldn't allow you to spawn a delegate.  Last I checked (which was admittedly a while ago), there were some compiler issues around actually verifying the function signature sent to spawn() though.

Why is foo a delegate here?

On Oct 18, 2012, at 11:35 AM, cal <callumenator@gmail.com> wrote:

> On Thursday, 18 October 2012 at 18:31:09 UTC, Sean Kelly wrote:
>> On Oct 17, 2012, at 11:29 PM, Joshua Niehus
>>> void foo(Tid tid) {
>>>   send(tid, true);
>>> }
> /* snip */
>> spawn() shouldn't allow you to spawn a delegate.  Last I checked (which was admittedly a while ago), there were some compiler issues around actually verifying the function signature sent to spawn() though.
> 
> Why is foo a delegate here?

My mistake.  I misread the example.

On Thursday, 18 October 2012 at 17:33:04 UTC, cal wrote:
>> I can't see the bug? The receiver accepts a bool as an int,
> same way a normal function does. The timeout is long enough that foo gets a chance to send.  If you want to stop the int receiver getting a bool, you could add another receiver with (bool) { // do nothing } or whatever before the (int) one, which will be a better match for the send.

I got myself into a situation where I dont know which will be called first, the int or the bool and "when" the call happens matters.

It was my assumption that "receiveTimeout(dur, (type){}); would distinguish between a bool and an int like it does for float and int.  But I can see why it would treat true/false as 0/1, so not a bug.

Anyway my current workaround is to define a few "Signal" structs and use those instead:
struct SignalReady { blah }
struct SignalXDone { blah }
struct SignalYDone { blah }

Thanks for the reply.