I think it's fair to cast shared away on certain core fns.
Sent by shouting through my showerhead.
On Jun 30, 2010, at 1:37 PM, Sean Kelly <[email protected]> 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.
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 <[email protected]
> 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 <[email protected]>
To: Discuss the phobos library for D <[email protected]>
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
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
