Great, thanks!  I can confirm that receiveTimeout() doesn't hang
anymore.

I just encountered another problem with the SVN version of std.concurrency.  The following code is a simplified version of an idiom which is used in TDPL, namely, sending a Tid as a message:

        import std.concurrency;

        void main()
        {
            Tid someTid;
            someTid.send(thisTid);
        }

Upon compilation, I get the following error:

/home/lars/code/phobos-trunk/phobos/std/concurrency.d(217): Error:
static assert  "Aliases to mutable thread-local data not allowed."
a.d(6):        instantiated from here: send!(Tid)

I do not get this message when I compile with the released (2.047)
version of std.concurrency.

-Lars


On Wed, 2010-06-30 at 11:36 -0700, Sean Kelly wrote:
> Okay, should be fixed now.
> 
> On Jun 30, 2010, at 8:38 AM, Sean Kelly wrote:
> 
> > Oh well, looks like I have even more fixing to do :-)
> > 
> > On Jun 30, 2010, at 7:35 AM, Lars Tandle Kyllingstad wrote:
> > 
> >> Yeah, I noticed that you committed the fix, but too late. :)  Due to some server lag, I got the "phobos commit" message several hours after I sent my e-mail, even though the commit was apparently done before I sent it.
> >> 
> >> In case it's useful, I should mention that even after fixing the tuple issue and changing the return type of receiveTimeout() to void, it still doesn't work.  The following code hangs indefinitely:
> >> 
> >>       import std.concurrency;
> >> 
> >>       void main()
> >>       {
> >>               // Should only block for 1ms:
> >>               receiveTimeout(1, (int i) { });
> >>       }
> >> 
> >> -Lars
> >> 
> >> 
> >> 
> >> On Tue, 2010-06-29 at 20:47 -0700, Sean Kelly wrote:
> >>> The code has changed a ton recently and I hadn't gotten around to testing receiveTimeout yet. I'll take care of it.
> >>> 
> >>> Sent from my iPhone
> >>> 
> >>> On Jun 29, 2010, at 4:09 PM, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> >>> 
> >>>> I'm guessing this error turned up because someone tried to use receiveTimeout().  That's when it happened for me, at least.  But when I fixed this, another error occurred:
> >>>> 
> >>>> receiveTimeout() is supposed to return a bool, but it tries to return
> >>>> the result of MessageBox.get(), which is void.  So get() should, in the
> >>>> case when ops[0] is an integer, somehow detect whether a message was
> >>>> received within the time limit and return a bool.
> >>>> 
> >>>> Sean, if you aren't working on this already, I can look into it if you like.
> >>>> 
> >>>> -Lars
> >>>> 
> >>>> 
> >>>> 
> >>>> On Tue, 2010-06-29 at 09:40 -0700, Sean Kelly wrote:
> >>>>> Okay I guess that makes sense.  Should be easy enough to fix anyway.
> >>>>> 
> >>>>> On Jun 29, 2010, at 8:43 AM, Steve Schveighoffer wrote:
> >>>>> 
> >>>>>> You can't slice a tuple and assign it back to the same tuple type.
> >>>>>> 
> >>>>>> -Steve
> >>>>>> 
> >>>>>> ----- Original Message ----
> >>>>>>> From: Sean Kelly <sean at invisibleduck.org>
> >>>>>>> To: Discuss the phobos library for D <phobos at puremagic.com>
> >>>>>>> Sent: Tue, June 29, 2010 11:39:50 AM
> >>>>>>> Subject: Re: [phobos] Typo (bug) in std.concurrency
> >>>>>>> 
> >>>>>>> On Jun 29, 2010, at 7:00 AM, Simen Kjaeraas wrote:
> >>>>>> 
> >>>>>>> 
> >>>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=4406
> >>>>>>> 
> >>>>>>> Posting it here too, to make sure it gets noticed. It's a rather simple fix.
> >>>>>> 
> >>>>>> You
> >>>>>>> can't slice a tuple?  Seriously?  I could have sworn that I tested this and it worked.
> >> 
> >> 
> >> _______________________________________________
> >> phobos mailing list
> >> phobos at puremagic.com
> >> http://lists.puremagic.com/mailman/listinfo/phobos
> > 
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Looks like it's time I start labeling references as shared in std.concurrency.  The static checking is new.

On Jun 30, 2010, at 12:15 PM, Lars Tandle Kyllingstad wrote:

> Great, thanks!  I can confirm that receiveTimeout() doesn't hang
> anymore.
> 
> I just encountered another problem with the SVN version of std.concurrency.  The following code is a simplified version of an idiom which is used in TDPL, namely, sending a Tid as a message:
> 
>        import std.concurrency;
> 
>        void main()
>        {
>            Tid someTid;
>            someTid.send(thisTid);
>        }
> 
> Upon compilation, I get the following error:
> 
> /home/lars/code/phobos-trunk/phobos/std/concurrency.d(217): Error:
> static assert  "Aliases to mutable thread-local data not allowed."
> a.d(6):        instantiated from here: send!(Tid)
> 
> I do not get this message when I compile with the released (2.047)
> version of std.concurrency.
> 
> -Lars
> 
> 
> On Wed, 2010-06-30 at 11:36 -0700, Sean Kelly wrote:
>> Okay, should be fixed now.
>> 
>> On Jun 30, 2010, at 8:38 AM, Sean Kelly wrote:
>> 
>>> Oh well, looks like I have even more fixing to do :-)
>>> 
>>> On Jun 30, 2010, at 7:35 AM, Lars Tandle Kyllingstad wrote:
>>> 
>>>> Yeah, I noticed that you committed the fix, but too late. :)  Due to some server lag, I got the "phobos commit" message several hours after I sent my e-mail, even though the commit was apparently done before I sent it.
>>>> 
>>>> In case it's useful, I should mention that even after fixing the tuple issue and changing the return type of receiveTimeout() to void, it still doesn't work.  The following code hangs indefinitely:
>>>> 
>>>>      import std.concurrency;
>>>> 
>>>>      void main()
>>>>      {
>>>>              // Should only block for 1ms:
>>>>              receiveTimeout(1, (int i) { });
>>>>      }
>>>> 
>>>> -Lars
>>>> 
>>>> 
>>>> 
>>>> On Tue, 2010-06-29 at 20:47 -0700, Sean Kelly wrote:
>>>>> The code has changed a ton recently and I hadn't gotten around to testing receiveTimeout yet. I'll take care of it.
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>> On Jun 29, 2010, at 4:09 PM, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
>>>>> 
>>>>>> I'm guessing this error turned up because someone tried to use receiveTimeout().  That's when it happened for me, at least.  But when I fixed this, another error occurred:
>>>>>> 
>>>>>> receiveTimeout() is supposed to return a bool, but it tries to return
>>>>>> the result of MessageBox.get(), which is void.  So get() should, in the
>>>>>> case when ops[0] is an integer, somehow detect whether a message was
>>>>>> received within the time limit and return a bool.
>>>>>> 
>>>>>> Sean, if you aren't working on this already, I can look into it if you like.
>>>>>> 
>>>>>> -Lars
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Tue, 2010-06-29 at 09:40 -0700, Sean Kelly wrote:
>>>>>>> Okay I guess that makes sense.  Should be easy enough to fix anyway.
>>>>>>> 
>>>>>>> On Jun 29, 2010, at 8:43 AM, Steve Schveighoffer wrote:
>>>>>>> 
>>>>>>>> You can't slice a tuple and assign it back to the same tuple type.
>>>>>>>> 
>>>>>>>> -Steve
>>>>>>>> 
>>>>>>>> ----- Original Message ----
>>>>>>>>> From: Sean Kelly <sean at invisibleduck.org>
>>>>>>>>> To: Discuss the phobos library for D <phobos at puremagic.com>
>>>>>>>>> Sent: Tue, June 29, 2010 11:39:50 AM
>>>>>>>>> Subject: Re: [phobos] Typo (bug) in std.concurrency
>>>>>>>>> 
>>>>>>>>> On Jun 29, 2010, at 7:00 AM, Simen Kjaeraas wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=4406
>>>>>>>>> 
>>>>>>>>> Posting it here too, to make sure it gets noticed. It's a rather simple fix.
>>>>>>>> 
>>>>>>>> You
>>>>>>>>> can't slice a tuple?  Seriously?  I could have sworn that I tested this and it worked.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> phobos mailing list
>>>> phobos at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>> 
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

This is somewhat unrelated, but the idea came to me as a workaround for the bug I just described:

Since there is an owner-owned relationship between threads, would it be a good idea to have an ownerTid() function?  I've noticed that there is a private 'owner' variable in std.concurrency, and I'm thinking something like this would be useful:

        @property Tid ownerTid()
        {
                enforce(owner, "Thread has no owner");
                return owner;
        }

-Lars

On Wed, 2010-06-30 at 12:27 -0700, Sean Kelly wrote:
> Looks like it's time I start labeling references as shared in std.concurrency.  The static checking is new.
> 
> On Jun 30, 2010, at 12:15 PM, Lars Tandle Kyllingstad wrote:
> 
> > Great, thanks!  I can confirm that receiveTimeout() doesn't hang
> > anymore.
> > 
> > I just encountered another problem with the SVN version of std.concurrency.  The following code is a simplified version of an idiom which is used in TDPL, namely, sending a Tid as a message:
> > 
> >        import std.concurrency;
> > 
> >        void main()
> >        {
> >            Tid someTid;
> >            someTid.send(thisTid);
> >        }
> > 
> > Upon compilation, I get the following error:
> > 
> > /home/lars/code/phobos-trunk/phobos/std/concurrency.d(217): Error:
> > static assert  "Aliases to mutable thread-local data not allowed."
> > a.d(6):        instantiated from here: send!(Tid)
> > 
> > I do not get this message when I compile with the released (2.047)
> > version of std.concurrency.
> > 
> > -Lars
> > 
> > 
> > On Wed, 2010-06-30 at 11:36 -0700, Sean Kelly wrote:
> >> Okay, should be fixed now.
> >> 
> >> On Jun 30, 2010, at 8:38 AM, Sean Kelly wrote:
> >> 
> >>> Oh well, looks like I have even more fixing to do :-)
> >>> 
> >>> On Jun 30, 2010, at 7:35 AM, Lars Tandle Kyllingstad wrote:
> >>> 
> >>>> Yeah, I noticed that you committed the fix, but too late. :)  Due to some server lag, I got the "phobos commit" message several hours after I sent my e-mail, even though the commit was apparently done before I sent it.
> >>>> 
> >>>> In case it's useful, I should mention that even after fixing the tuple issue and changing the return type of receiveTimeout() to void, it still doesn't work.  The following code hangs indefinitely:
> >>>> 
> >>>>      import std.concurrency;
> >>>> 
> >>>>      void main()
> >>>>      {
> >>>>              // Should only block for 1ms:
> >>>>              receiveTimeout(1, (int i) { });
> >>>>      }
> >>>> 
> >>>> -Lars
> >>>> 
> >>>> 
> >>>> 
> >>>> On Tue, 2010-06-29 at 20:47 -0700, Sean Kelly wrote:
> >>>>> The code has changed a ton recently and I hadn't gotten around to testing receiveTimeout yet. I'll take care of it.
> >>>>> 
> >>>>> Sent from my iPhone
> >>>>> 
> >>>>> On Jun 29, 2010, at 4:09 PM, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> >>>>> 
> >>>>>> I'm guessing this error turned up because someone tried to use receiveTimeout().  That's when it happened for me, at least.  But when I fixed this, another error occurred:
> >>>>>> 
> >>>>>> receiveTimeout() is supposed to return a bool, but it tries to return
> >>>>>> the result of MessageBox.get(), which is void.  So get() should, in the
> >>>>>> case when ops[0] is an integer, somehow detect whether a message was
> >>>>>> received within the time limit and return a bool.
> >>>>>> 
> >>>>>> Sean, if you aren't working on this already, I can look into it if you like.
> >>>>>> 
> >>>>>> -Lars
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> On Tue, 2010-06-29 at 09:40 -0700, Sean Kelly wrote:
> >>>>>>> Okay I guess that makes sense.  Should be easy enough to fix anyway.
> >>>>>>> 
> >>>>>>> On Jun 29, 2010, at 8:43 AM, Steve Schveighoffer wrote:
> >>>>>>> 
> >>>>>>>> You can't slice a tuple and assign it back to the same tuple type.
> >>>>>>>> 
> >>>>>>>> -Steve
> >>>>>>>> 
> >>>>>>>> ----- Original Message ----
> >>>>>>>>> From: Sean Kelly <sean at invisibleduck.org>
> >>>>>>>>> To: Discuss the phobos library for D <phobos at puremagic.com>
> >>>>>>>>> Sent: Tue, June 29, 2010 11:39:50 AM
> >>>>>>>>> Subject: Re: [phobos] Typo (bug) in std.concurrency
> >>>>>>>>> 
> >>>>>>>>> On Jun 29, 2010, at 7:00 AM, Simen Kjaeraas wrote:
> >>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=4406
> >>>>>>>>> 
> >>>>>>>>> Posting it here too, to make sure it gets noticed. It's a rather simple fix.
> >>>>>>>> 
> >>>>>>>> You
> >>>>>>>>> can't slice a tuple?  Seriously?  I could have sworn that I tested this and it worked.
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> phobos mailing list
> >>>> phobos at puremagic.com
> >>>> http://lists.puremagic.com/mailman/listinfo/phobos
> >>> 
> >>> _______________________________________________
> >>> phobos mailing list
> >>> phobos at puremagic.com
> >>> http://lists.puremagic.com/mailman/listinfo/phobos
> >> 
> >> _______________________________________________
> >> phobos mailing list
> >> phobos at puremagic.com
> >> http://lists.puremagic.com/mailman/listinfo/phobos
> > 
> > 
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Sounds like a good idea.

On Jun 30, 2010, at 12:32 PM, Lars Tandle Kyllingstad wrote:

> This is somewhat unrelated, but the idea came to me as a workaround for the bug I just described:
> 
> Since there is an owner-owned relationship between threads, would it be a good idea to have an ownerTid() function?  I've noticed that there is a private 'owner' variable in std.concurrency, and I'm thinking something like this would be useful:
> 
>        @property Tid ownerTid()
>        {
>                enforce(owner, "Thread has no owner");
>                return owner;
>        }
> 
> -Lars
> 
> On Wed, 2010-06-30 at 12:27 -0700, Sean Kelly wrote:
>> Looks like it's time I start labeling references as shared in std.concurrency.  The static checking is new.
>> 
>> On Jun 30, 2010, at 12:15 PM, Lars Tandle Kyllingstad wrote:
>> 
>>> Great, thanks!  I can confirm that receiveTimeout() doesn't hang
>>> anymore.
>>> 
>>> I just encountered another problem with the SVN version of std.concurrency.  The following code is a simplified version of an idiom which is used in TDPL, namely, sending a Tid as a message:
>>> 
>>>       import std.concurrency;
>>> 
>>>       void main()
>>>       {
>>>           Tid someTid;
>>>           someTid.send(thisTid);
>>>       }
>>> 
>>> Upon compilation, I get the following error:
>>> 
>>> /home/lars/code/phobos-trunk/phobos/std/concurrency.d(217): Error:
>>> static assert  "Aliases to mutable thread-local data not allowed."
>>> a.d(6):        instantiated from here: send!(Tid)
>>> 
>>> I do not get this message when I compile with the released (2.047)
>>> version of std.concurrency.
>>> 
>>> -Lars
>>> 
>>> 
>>> On Wed, 2010-06-30 at 11:36 -0700, Sean Kelly wrote:
>>>> Okay, should be fixed now.
>>>> 
>>>> On Jun 30, 2010, at 8:38 AM, Sean Kelly wrote:
>>>> 
>>>>> Oh well, looks like I have even more fixing to do :-)
>>>>> 
>>>>> On Jun 30, 2010, at 7:35 AM, Lars Tandle Kyllingstad wrote:
>>>>> 
>>>>>> Yeah, I noticed that you committed the fix, but too late. :)  Due to some server lag, I got the "phobos commit" message several hours after I sent my e-mail, even though the commit was apparently done before I sent it.
>>>>>> 
>>>>>> In case it's useful, I should mention that even after fixing the tuple issue and changing the return type of receiveTimeout() to void, it still doesn't work.  The following code hangs indefinitely:
>>>>>> 
>>>>>>     import std.concurrency;
>>>>>> 
>>>>>>     void main()
>>>>>>     {
>>>>>>             // Should only block for 1ms:
>>>>>>             receiveTimeout(1, (int i) { });
>>>>>>     }
>>>>>> 
>>>>>> -Lars
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Tue, 2010-06-29 at 20:47 -0700, Sean Kelly wrote:
>>>>>>> The code has changed a ton recently and I hadn't gotten around to testing receiveTimeout yet. I'll take care of it.
>>>>>>> 
>>>>>>> Sent from my iPhone
>>>>>>> 
>>>>>>> On Jun 29, 2010, at 4:09 PM, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
>>>>>>> 
>>>>>>>> I'm guessing this error turned up because someone tried to use receiveTimeout().  That's when it happened for me, at least.  But when I fixed this, another error occurred:
>>>>>>>> 
>>>>>>>> receiveTimeout() is supposed to return a bool, but it tries to return
>>>>>>>> the result of MessageBox.get(), which is void.  So get() should, in the
>>>>>>>> case when ops[0] is an integer, somehow detect whether a message was
>>>>>>>> received within the time limit and return a bool.
>>>>>>>> 
>>>>>>>> Sean, if you aren't working on this already, I can look into it if you like.
>>>>>>>> 
>>>>>>>> -Lars
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Tue, 2010-06-29 at 09:40 -0700, Sean Kelly wrote:
>>>>>>>>> Okay I guess that makes sense.  Should be easy enough to fix anyway.
>>>>>>>>> 
>>>>>>>>> On Jun 29, 2010, at 8:43 AM, Steve Schveighoffer wrote:
>>>>>>>>> 
>>>>>>>>>> You can't slice a tuple and assign it back to the same tuple type.
>>>>>>>>>> 
>>>>>>>>>> -Steve
>>>>>>>>>> 
>>>>>>>>>> ----- Original Message ----
>>>>>>>>>>> From: Sean Kelly <sean at invisibleduck.org>
>>>>>>>>>>> To: Discuss the phobos library for D <phobos at puremagic.com>
>>>>>>>>>>> Sent: Tue, June 29, 2010 11:39:50 AM
>>>>>>>>>>> Subject: Re: [phobos] Typo (bug) in std.concurrency
>>>>>>>>>>> 
>>>>>>>>>>> On Jun 29, 2010, at 7:00 AM, Simen Kjaeraas wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=4406
>>>>>>>>>>> 
>>>>>>>>>>> Posting it here too, to make sure it gets noticed. It's a rather simple fix.
>>>>>>>>>> 
>>>>>>>>>> You
>>>>>>>>>>> can't slice a tuple?  Seriously?  I could have sworn that I tested this and it worked.
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> phobos mailing list
>>>>>> phobos at puremagic.com
>>>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>>> 
>>>>> _______________________________________________
>>>>> phobos mailing list
>>>>> phobos at puremagic.com
>>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>> 
>>>> _______________________________________________
>>>> phobos mailing list
>>>> phobos at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>> 
>>> 
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Well that was a disaster.  I have this:

class MessageBox
{
    this()
    {
        // this makes m_lock the monitor for the MessageBox instance.
        m_lock = new Mutex( this );
        m_cond = new Condition( m_lock );
    }

    final synchronized void put( Message msg )
    {
        // m_lock is locked now
        m_list.add( msg );
        m_cond.notify(); // error: notify () is not callable using argument types () shared
    }
}

struct Tid
{
    shared MessageBox mbox;
}

class Condition
{
    void notify()
    {
        // fancy stuff involving semaphores
    }
}

How do I fix this?  Condition.notify() is technically shared, but I don't want to pay the cost for memory barriers that are utterly pointless.  Should I change the call to notify() to:

(cast(Condition)m_cond).notify();

This should work, but it seems like an even worse subversion of the shared system than I'm already doing for MessageBox.  If it helps, MessageBox is a thread-local class instance with put() as its one shared public method, so other threads have a shared reference to MessageBox while the object's owner has a non-shared reference to it.  This is functionally correct, though it seems theoretically wrong to have both shared and unshared references to the same instance in the first place.


On Jun 30, 2010, at 12:27 PM, Sean Kelly wrote:

> Looks like it's time I start labeling references as shared in std.concurrency.  The static checking is new.
> 
> On Jun 30, 2010, at 12:15 PM, Lars Tandle Kyllingstad wrote:
> 
>> Great, thanks!  I can confirm that receiveTimeout() doesn't hang
>> anymore.
>> 
>> I just encountered another problem with the SVN version of std.concurrency.  The following code is a simplified version of an idiom which is used in TDPL, namely, sending a Tid as a message:
>> 
>>       import std.concurrency;
>> 
>>       void main()
>>       {
>>           Tid someTid;
>>           someTid.send(thisTid);
>>       }
>> 
>> Upon compilation, I get the following error:
>> 
>> /home/lars/code/phobos-trunk/phobos/std/concurrency.d(217): Error:
>> static assert  "Aliases to mutable thread-local data not allowed."
>> a.d(6):        instantiated from here: send!(Tid)
>> 
>> I do not get this message when I compile with the released (2.047)
>> version of std.concurrency.
>> 
>> -Lars
>> 
>> 
>> On Wed, 2010-06-30 at 11:36 -0700, Sean Kelly wrote:
>>> Okay, should be fixed now.
>>> 
>>> On Jun 30, 2010, at 8:38 AM, Sean Kelly wrote:
>>> 
>>>> Oh well, looks like I have even more fixing to do :-)
>>>> 
>>>> On Jun 30, 2010, at 7:35 AM, Lars Tandle Kyllingstad wrote:
>>>> 
>>>>> Yeah, I noticed that you committed the fix, but too late. :)  Due to some server lag, I got the "phobos commit" message several hours after I sent my e-mail, even though the commit was apparently done before I sent it.
>>>>> 
>>>>> In case it's useful, I should mention that even after fixing the tuple issue and changing the return type of receiveTimeout() to void, it still doesn't work.  The following code hangs indefinitely:
>>>>> 
>>>>>     import std.concurrency;
>>>>> 
>>>>>     void main()
>>>>>     {
>>>>>             // Should only block for 1ms:
>>>>>             receiveTimeout(1, (int i) { });
>>>>>     }
>>>>> 
>>>>> -Lars
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, 2010-06-29 at 20:47 -0700, Sean Kelly wrote:
>>>>>> The code has changed a ton recently and I hadn't gotten around to testing receiveTimeout yet. I'll take care of it.
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>> On Jun 29, 2010, at 4:09 PM, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
>>>>>> 
>>>>>>> I'm guessing this error turned up because someone tried to use receiveTimeout().  That's when it happened for me, at least.  But when I fixed this, another error occurred:
>>>>>>> 
>>>>>>> receiveTimeout() is supposed to return a bool, but it tries to return
>>>>>>> the result of MessageBox.get(), which is void.  So get() should, in the
>>>>>>> case when ops[0] is an integer, somehow detect whether a message was
>>>>>>> received within the time limit and return a bool.
>>>>>>> 
>>>>>>> Sean, if you aren't working on this already, I can look into it if you like.
>>>>>>> 
>>>>>>> -Lars
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, 2010-06-29 at 09:40 -0700, Sean Kelly wrote:
>>>>>>>> Okay I guess that makes sense.  Should be easy enough to fix anyway.
>>>>>>>> 
>>>>>>>> On Jun 29, 2010, at 8:43 AM, Steve Schveighoffer wrote:
>>>>>>>> 
>>>>>>>>> You can't slice a tuple and assign it back to the same tuple type.
>>>>>>>>> 
>>>>>>>>> -Steve
>>>>>>>>> 
>>>>>>>>> ----- Original Message ----
>>>>>>>>>> From: Sean Kelly <sean at invisibleduck.org>
>>>>>>>>>> To: Discuss the phobos library for D <phobos at puremagic.com>
>>>>>>>>>> Sent: Tue, June 29, 2010 11:39:50 AM
>>>>>>>>>> Subject: Re: [phobos] Typo (bug) in std.concurrency
>>>>>>>>>> 
>>>>>>>>>> On Jun 29, 2010, at 7:00 AM, Simen Kjaeraas wrote:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=4406
>>>>>>>>>> 
>>>>>>>>>> Posting it here too, to make sure it gets noticed. It's a rather simple fix.
>>>>>>>>> 
>>>>>>>>> You
>>>>>>>>>> can't slice a tuple?  Seriously?  I could have sworn that I tested this and it worked.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> phobos mailing list
>>>>> phobos at puremagic.com
>>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>> 
>>>> _______________________________________________
>>>> phobos mailing list
>>>> phobos at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>> 
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Okay, alternate evil solution:

class Condition
{
    shared void notify()
    {
        static void doNotify() {}
        (cast(Condition) this).doNotify();
    }
}

Seems like it should work, though I'm hoping that the classes in core.sync are about the only ones where it's necessary (something similar will probably be necessary for Mutex to make lock() and unlock() explicitly callable, etc).  I'm half tempted to try labeling these functions as __gshared and see if it compiles.

On Jun 30, 2010, at 1:24 PM, Sean Kelly wrote:

> Well that was a disaster.  I have this:
> 
> class MessageBox
> {
>    this()
>    {
>        // this makes m_lock the monitor for the MessageBox instance.
>        m_lock = new Mutex( this );
>        m_cond = new Condition( m_lock );
>    }
> 
>    final synchronized void put( Message msg )
>    {
>        // m_lock is locked now
>        m_list.add( msg );
>        m_cond.notify(); // error: notify () is not callable using argument types () shared
>    }
> }
> 
> struct Tid
> {
>    shared MessageBox mbox;
> }
> 
> class Condition
> {
>    void notify()
>    {
>        // fancy stuff involving semaphores
>    }
> }
> 
> How do I fix this?  Condition.notify() is technically shared, but I don't want to pay the cost for memory barriers that are utterly pointless.  Should I change the call to notify() to:
> 
> (cast(Condition)m_cond).notify();
> 
> This should work, but it seems like an even worse subversion of the shared system than I'm already doing for MessageBox.  If it helps, MessageBox is a thread-local class instance with put() as its one shared public method, so other threads have a shared reference to MessageBox while the object's owner has a non-shared reference to it.  This is functionally correct, though it seems theoretically wrong to have both shared and unshared references to the same instance in the first place.
> 
> 
> On Jun 30, 2010, at 12:27 PM, Sean Kelly wrote:
> 
>> Looks like it's time I start labeling references as shared in std.concurrency.  The static checking is new.
>> 
>> On Jun 30, 2010, at 12:15 PM, Lars Tandle Kyllingstad wrote:
>> 
>>> Great, thanks!  I can confirm that receiveTimeout() doesn't hang
>>> anymore.
>>> 
>>> I just encountered another problem with the SVN version of std.concurrency.  The following code is a simplified version of an idiom which is used in TDPL, namely, sending a Tid as a message:
>>> 
>>>      import std.concurrency;
>>> 
>>>      void main()
>>>      {
>>>          Tid someTid;
>>>          someTid.send(thisTid);
>>>      }
>>> 
>>> Upon compilation, I get the following error:
>>> 
>>> /home/lars/code/phobos-trunk/phobos/std/concurrency.d(217): Error:
>>> static assert  "Aliases to mutable thread-local data not allowed."
>>> a.d(6):        instantiated from here: send!(Tid)
>>> 
>>> I do not get this message when I compile with the released (2.047)
>>> version of std.concurrency.
>>> 
>>> -Lars
>>> 
>>> 
>>> On Wed, 2010-06-30 at 11:36 -0700, Sean Kelly wrote:
>>>> Okay, should be fixed now.
>>>> 
>>>> On Jun 30, 2010, at 8:38 AM, Sean Kelly wrote:
>>>> 
>>>>> Oh well, looks like I have even more fixing to do :-)
>>>>> 
>>>>> On Jun 30, 2010, at 7:35 AM, Lars Tandle Kyllingstad wrote:
>>>>> 
>>>>>> Yeah, I noticed that you committed the fix, but too late. :)  Due to some server lag, I got the "phobos commit" message several hours after I sent my e-mail, even though the commit was apparently done before I sent it.
>>>>>> 
>>>>>> In case it's useful, I should mention that even after fixing the tuple issue and changing the return type of receiveTimeout() to void, it still doesn't work.  The following code hangs indefinitely:
>>>>>> 
>>>>>>    import std.concurrency;
>>>>>> 
>>>>>>    void main()
>>>>>>    {
>>>>>>            // Should only block for 1ms:
>>>>>>            receiveTimeout(1, (int i) { });
>>>>>>    }
>>>>>> 
>>>>>> -Lars
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Tue, 2010-06-29 at 20:47 -0700, Sean Kelly wrote:
>>>>>>> The code has changed a ton recently and I hadn't gotten around to testing receiveTimeout yet. I'll take care of it.
>>>>>>> 
>>>>>>> Sent from my iPhone
>>>>>>> 
>>>>>>> On Jun 29, 2010, at 4:09 PM, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
>>>>>>> 
>>>>>>>> I'm guessing this error turned up because someone tried to use receiveTimeout().  That's when it happened for me, at least.  But when I fixed this, another error occurred:
>>>>>>>> 
>>>>>>>> receiveTimeout() is supposed to return a bool, but it tries to return
>>>>>>>> the result of MessageBox.get(), which is void.  So get() should, in the
>>>>>>>> case when ops[0] is an integer, somehow detect whether a message was
>>>>>>>> received within the time limit and return a bool.
>>>>>>>> 
>>>>>>>> Sean, if you aren't working on this already, I can look into it if you like.
>>>>>>>> 
>>>>>>>> -Lars
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Tue, 2010-06-29 at 09:40 -0700, Sean Kelly wrote:
>>>>>>>>> Okay I guess that makes sense.  Should be easy enough to fix anyway.
>>>>>>>>> 
>>>>>>>>> On Jun 29, 2010, at 8:43 AM, Steve Schveighoffer wrote:
>>>>>>>>> 
>>>>>>>>>> You can't slice a tuple and assign it back to the same tuple type.
>>>>>>>>>> 
>>>>>>>>>> -Steve
>>>>>>>>>> 
>>>>>>>>>> ----- Original Message ----
>>>>>>>>>>> From: Sean Kelly <sean at invisibleduck.org>
>>>>>>>>>>> To: Discuss the phobos library for D <phobos at puremagic.com>
>>>>>>>>>>> Sent: Tue, June 29, 2010 11:39:50 AM
>>>>>>>>>>> Subject: Re: [phobos] Typo (bug) in std.concurrency
>>>>>>>>>>> 
>>>>>>>>>>> On Jun 29, 2010, at 7:00 AM, Simen Kjaeraas wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=4406
>>>>>>>>>>> 
>>>>>>>>>>> Posting it here too, to make sure it gets noticed. It's a rather simple fix.
>>>>>>>>>> 
>>>>>>>>>> You
>>>>>>>>>>> can't slice a tuple?  Seriously?  I could have sworn that I tested this and it worked.
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> phobos mailing list
>>>>>> phobos at puremagic.com
>>>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>>> 
>>>>> _______________________________________________
>>>>> phobos mailing list
>>>>> phobos at puremagic.com
>>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>> 
>>>> _______________________________________________
>>>> phobos mailing list
>>>> phobos at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>> 
>>> 
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

I hate to be the one throwing all these problems at you, but here's another one.  The following compiles and runs without error:

        import std.concurrency;

        void foo(int i) { }

        void main()
        {
                spawn(&foo);
                spawn(&foo, "hello world");
                spawn(&foo, "hello world", 3.14);
        }

Basically, it seems you can pass any set of parameters to spawn().  They don't have to match foo()'s.  Note that a thread does indeed get spawned in all of the cases above, and the parameter i contains a nonsense value.

-Lars



On Wed, 2010-06-30 at 12:27 -0700, Sean Kelly wrote:
> Looks like it's time I start labeling references as shared in std.concurrency.  The static checking is new.
> 
> On Jun 30, 2010, at 12:15 PM, Lars Tandle Kyllingstad wrote:
> 
> > Great, thanks!  I can confirm that receiveTimeout() doesn't hang
> > anymore.
> > 
> > I just encountered another problem with the SVN version of std.concurrency.  The following code is a simplified version of an idiom which is used in TDPL, namely, sending a Tid as a message:
> > 
> >        import std.concurrency;
> > 
> >        void main()
> >        {
> >            Tid someTid;
> >            someTid.send(thisTid);
> >        }
> > 
> > Upon compilation, I get the following error:
> > 
> > /home/lars/code/phobos-trunk/phobos/std/concurrency.d(217): Error:
> > static assert  "Aliases to mutable thread-local data not allowed."
> > a.d(6):        instantiated from here: send!(Tid)
> > 
> > I do not get this message when I compile with the released (2.047)
> > version of std.concurrency.
> > 
> > -Lars
> > 
> > 
> > On Wed, 2010-06-30 at 11:36 -0700, Sean Kelly wrote:
> >> Okay, should be fixed now.
> >> 
> >> On Jun 30, 2010, at 8:38 AM, Sean Kelly wrote:
> >> 
> >>> Oh well, looks like I have even more fixing to do :-)
> >>> 
> >>> On Jun 30, 2010, at 7:35 AM, Lars Tandle Kyllingstad wrote:
> >>> 
> >>>> Yeah, I noticed that you committed the fix, but too late. :)  Due to some server lag, I got the "phobos commit" message several hours after I sent my e-mail, even though the commit was apparently done before I sent it.
> >>>> 
> >>>> In case it's useful, I should mention that even after fixing the tuple issue and changing the return type of receiveTimeout() to void, it still doesn't work.  The following code hangs indefinitely:
> >>>> 
> >>>>      import std.concurrency;
> >>>> 
> >>>>      void main()
> >>>>      {
> >>>>              // Should only block for 1ms:
> >>>>              receiveTimeout(1, (int i) { });
> >>>>      }
> >>>> 
> >>>> -Lars
> >>>> 
> >>>> 
> >>>> 
> >>>> On Tue, 2010-06-29 at 20:47 -0700, Sean Kelly wrote:
> >>>>> The code has changed a ton recently and I hadn't gotten around to testing receiveTimeout yet. I'll take care of it.
> >>>>> 
> >>>>> Sent from my iPhone
> >>>>> 
> >>>>> On Jun 29, 2010, at 4:09 PM, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> >>>>> 
> >>>>>> I'm guessing this error turned up because someone tried to use receiveTimeout().  That's when it happened for me, at least.  But when I fixed this, another error occurred:
> >>>>>> 
> >>>>>> receiveTimeout() is supposed to return a bool, but it tries to return
> >>>>>> the result of MessageBox.get(), which is void.  So get() should, in the
> >>>>>> case when ops[0] is an integer, somehow detect whether a message was
> >>>>>> received within the time limit and return a bool.
> >>>>>> 
> >>>>>> Sean, if you aren't working on this already, I can look into it if you like.
> >>>>>> 
> >>>>>> -Lars
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> On Tue, 2010-06-29 at 09:40 -0700, Sean Kelly wrote:
> >>>>>>> Okay I guess that makes sense.  Should be easy enough to fix anyway.
> >>>>>>> 
> >>>>>>> On Jun 29, 2010, at 8:43 AM, Steve Schveighoffer wrote:
> >>>>>>> 
> >>>>>>>> You can't slice a tuple and assign it back to the same tuple type.
> >>>>>>>> 
> >>>>>>>> -Steve
> >>>>>>>> 
> >>>>>>>> ----- Original Message ----
> >>>>>>>>> From: Sean Kelly <sean at invisibleduck.org>
> >>>>>>>>> To: Discuss the phobos library for D <phobos at puremagic.com>
> >>>>>>>>> Sent: Tue, June 29, 2010 11:39:50 AM
> >>>>>>>>> Subject: Re: [phobos] Typo (bug) in std.concurrency
> >>>>>>>>> 
> >>>>>>>>> On Jun 29, 2010, at 7:00 AM, Simen Kjaeraas wrote:
> >>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=4406
> >>>>>>>>> 
> >>>>>>>>> Posting it here too, to make sure it gets noticed. It's a rather simple fix.
> >>>>>>>> 
> >>>>>>>> You
> >>>>>>>>> can't slice a tuple?  Seriously?  I could have sworn that I tested this and it worked.
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> phobos mailing list
> >>>> phobos at puremagic.com
> >>>> http://lists.puremagic.com/mailman/listinfo/phobos
> >>> 
> >>> _______________________________________________
> >>> phobos mailing list
> >>> phobos at puremagic.com
> >>> http://lists.puremagic.com/mailman/listinfo/phobos
> >> 
> >> _______________________________________________
> >> phobos mailing list
> >> phobos at puremagic.com
> >> http://lists.puremagic.com/mailman/listinfo/phobos
> > 
> > 
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Jun 30, 2010, at 9:10 PM, Lars Tandle Kyllingstad wrote:

> I hate to be the one throwing all these problems at you, but here's another one.  The following compiles and runs without error:
> 
>        import std.concurrency;
> 
>        void foo(int i) { }
> 
>        void main()
>        {
>                spawn(&foo);
>                spawn(&foo, "hello world");
>                spawn(&foo, "hello world", 3.14);
>        }
> 
> Basically, it seems you can pass any set of parameters to spawn().  They don't have to match foo()'s.  Note that a thread does indeed get spawned in all of the cases above, and the parameter i contains a nonsense value.

That doesn't make any sense.  Here's the code for spawn:

private Tid spawn_(T...)( bool linked, void function(T) fn, T args )
{
    // TODO: MessageList and &exec should be shared.
    auto spawnTid = Tid( new MessageBox );
    auto ownerTid = thisTid;

    void exec()
    {
        mbox  = spawnTid.mbox;
        owner = ownerTid;
        fn( args );
    }

    auto t = new Thread( &exec ); t.start();
    links[spawnTid] = linked;
    return spawnTid;
}

Why would it compile if the wrong args were supplied?  Can someone confirm this is a compiler bug?

As I'd feared, this is getting more and more complicated.  I tried making the lock() and unlock() methods in Mutex shared and now I'm getting these errors:

xtest.d(98): Error: function core.sys.posix.pthread.pthread_mutex_lock (pthread_mutex_t*) is not callable using argument types (shared(pthread_mutex_t)*)
xtest.d(98): Error: cannot implicitly convert expression (&this.m_hndl) of type shared(pthread_mutex_t)* to pthread_mutex_t*
xtest.d(120): Error: function core.sys.posix.pthread.pthread_mutex_unlock (pthread_mutex_t*) is not callable using argument types (shared(pthread_mutex_t)*)
xtest.d(120): Error: cannot implicitly convert expression (&this.m_hndl) of type shared(pthread_mutex_t)* to pthread_mutex_t*
xtest.d(146): Error: function core.sys.posix.pthread.pthread_mutex_trylock (pthread_mutex_t*) is not callable using argument types (shared(pthread_mutex_t)*)
xtest.d(146): Error: cannot implicitly convert expression (&this.m_hndl) of type shared(pthread_mutex_t)* to pthread_mutex_t*

While technically correct, I find this behavior quite frustrating.  I suppose I could go through the Posix API and mark all the thread stuff as shared to make sure it will compile correctly, but that would break any existing code that is using this stuff in an unshared data type (ie. basically everyone), and since these are extern (C) routines I can't overload them on shared either.  The simplest alternative fix I've found so far is basically what I described below:

class Mutex
{
    shared void lock()
    {
        (cast(Mutex) this).doLock();
    }

    private void doLock()
    {
        // lock the mutex
    }
}

I'm coming to wish there were a way to tell the compiler "this is part of the TCB, shut up, I know what I'm doing."

I think for the next release I'm simply going to allow sending Tid instances regardless of whether they contain an unshared reference so I can have more time to figure out the best way to handle this.

On Jun 30, 2010, at 1:37 PM, Sean Kelly wrote:

> Okay, alternate evil solution:
> 
> class Condition
> {
>    shared void notify()
>    {
>        static void doNotify() {}
>        (cast(Condition) this).doNotify();
>    }
> }
> 
> Seems like it should work, though I'm hoping that the classes in core.sync are about the only ones where it's necessary (something similar will probably be necessary for Mutex to make lock() and unlock() explicitly callable, etc).  I'm half tempted to try labeling these functions as __gshared and see if it compiles.
> 
> On Jun 30, 2010, at 1:24 PM, Sean Kelly wrote:
> 
>> Well that was a disaster.  I have this:
>> 
>> class MessageBox
>> {
>>   this()
>>   {
>>       // this makes m_lock the monitor for the MessageBox instance.
>>       m_lock = new Mutex( this );
>>       m_cond = new Condition( m_lock );
>>   }
>> 
>>   final synchronized void put( Message msg )
>>   {
>>       // m_lock is locked now
>>       m_list.add( msg );
>>       m_cond.notify(); // error: notify () is not callable using argument types () shared
>>   }
>> }
>> 
>> struct Tid
>> {
>>   shared MessageBox mbox;
>> }
>> 
>> class Condition
>> {
>>   void notify()
>>   {
>>       // fancy stuff involving semaphores
>>   }
>> }
>> 
>> How do I fix this?  Condition.notify() is technically shared, but I don't want to pay the cost for memory barriers that are utterly pointless.  Should I change the call to notify() to:
>> 
>> (cast(Condition)m_cond).notify();
>> 
>> This should work, but it seems like an even worse subversion of the shared system than I'm already doing for MessageBox.  If it helps, MessageBox is a thread-local class instance with put() as its one shared public method, so other threads have a shared reference to MessageBox while the object's owner has a non-shared reference to it.  This is functionally correct, though it seems theoretically wrong to have both shared and unshared references to the same instance in the first place.

I think we should bite the bullet and mark the signatures as shared.

Andrei

Sean Kelly wrote:
> As I'd feared, this is getting more and more complicated.  I tried making the lock() and unlock() methods in Mutex shared and now I'm getting these errors:
> 
> xtest.d(98): Error: function core.sys.posix.pthread.pthread_mutex_lock (pthread_mutex_t*) is not callable using argument types (shared(pthread_mutex_t)*)
> xtest.d(98): Error: cannot implicitly convert expression (&this.m_hndl) of type shared(pthread_mutex_t)* to pthread_mutex_t*
> xtest.d(120): Error: function core.sys.posix.pthread.pthread_mutex_unlock (pthread_mutex_t*) is not callable using argument types (shared(pthread_mutex_t)*)
> xtest.d(120): Error: cannot implicitly convert expression (&this.m_hndl) of type shared(pthread_mutex_t)* to pthread_mutex_t*
> xtest.d(146): Error: function core.sys.posix.pthread.pthread_mutex_trylock (pthread_mutex_t*) is not callable using argument types (shared(pthread_mutex_t)*)
> xtest.d(146): Error: cannot implicitly convert expression (&this.m_hndl) of type shared(pthread_mutex_t)* to pthread_mutex_t*
> 
> While technically correct, I find this behavior quite frustrating.  I suppose I could go through the Posix API and mark all the thread stuff as shared to make sure it will compile correctly, but that would break any existing code that is using this stuff in an unshared data type (ie. basically everyone), and since these are extern (C) routines I can't overload them on shared either.  The simplest alternative fix I've found so far is basically what I described below:
> 
> class Mutex
> {
>     shared void lock()
>     {
>         (cast(Mutex) this).doLock();
>     }
> 
>     private void doLock()
>     {
>         // lock the mutex
>     }
> }
> 
> I'm coming to wish there were a way to tell the compiler "this is part of the TCB, shut up, I know what I'm doing."
> 
> I think for the next release I'm simply going to allow sending Tid instances regardless of whether they contain an unshared reference so I can have more time to figure out the best way to handle this.
> 
> On Jun 30, 2010, at 1:37 PM, Sean Kelly wrote:
> 
>> Okay, alternate evil solution:
>>
>> class Condition
>> {
>>    shared void notify()
>>    {
>>        static void doNotify() {}
>>        (cast(Condition) this).doNotify();
>>    }
>> }
>>
>> Seems like it should work, though I'm hoping that the classes in core.sync are about the only ones where it's necessary (something similar will probably be necessary for Mutex to make lock() and unlock() explicitly callable, etc).  I'm half tempted to try labeling these functions as __gshared and see if it compiles.
>>
>> On Jun 30, 2010, at 1:24 PM, Sean Kelly wrote:
>>
>>> Well that was a disaster.  I have this:
>>>
>>> class MessageBox
>>> {
>>>   this()
>>>   {
>>>       // this makes m_lock the monitor for the MessageBox instance.
>>>       m_lock = new Mutex( this );
>>>       m_cond = new Condition( m_lock );
>>>   }
>>>
>>>   final synchronized void put( Message msg )
>>>   {
>>>       // m_lock is locked now
>>>       m_list.add( msg );
>>>       m_cond.notify(); // error: notify () is not callable using argument types () shared
>>>   }
>>> }
>>>
>>> struct Tid
>>> {
>>>   shared MessageBox mbox;
>>> }
>>>
>>> class Condition
>>> {
>>>   void notify()
>>>   {
>>>       // fancy stuff involving semaphores
>>>   }
>>> }
>>>
>>> How do I fix this?  Condition.notify() is technically shared, but I don't want to pay the cost for memory barriers that are utterly pointless.  Should I change the call to notify() to:
>>>
>>> (cast(Condition)m_cond).notify();
>>>
>>> This should work, but it seems like an even worse subversion of the shared system than I'm already doing for MessageBox.  If it helps, MessageBox is a thread-local class instance with put() as its one shared public method, so other threads have a shared reference to MessageBox while the object's owner has a non-shared reference to it.  This is functionally correct, though it seems theoretically wrong to have both shared and unshared references to the same instance in the first place.
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos