View mode: basic / threaded / horizontal-split · Log in · Help
July 17, 2011
std.concurrency.spawn does not accept delegates
It looks like std.concurrency.spawn does not accept delegates. Is there 
any reason for that?
July 18, 2011
Re: std.concurrency.spawn does not accept delegates
On Sunday 17 July 2011 19:29:02 teo wrote:
> It looks like std.concurrency.spawn does not accept delegates. Is there
> any reason for that?

Probably because it would have to accept a delegate where every variable that 
it had access too outside of its own scope was immutable, and I don't think 
that there's any way for the compiler to make such guarantees with a delegate.

- Jonathan M Davis
July 18, 2011
Re: std.concurrency.spawn does not accept delegates
On Sun, 17 Jul 2011 15:29:02 -0400, teo <teo.ubuntu@yahoo.com> wrote:

> It looks like std.concurrency.spawn does not accept delegates. Is there
> any reason for that?

There is no type attached to the hidden 'this' pointer.  So spawn cannot  
guarantee it doesn't point to unshared data.

-Steve
July 18, 2011
Re: std.concurrency.spawn does not accept delegates
On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer wrote:

> On Sun, 17 Jul 2011 15:29:02 -0400, teo <teo.ubuntu@yahoo.com> wrote:
> 
>> It looks like std.concurrency.spawn does not accept delegates. Is there
>> any reason for that?
> 
> There is no type attached to the hidden 'this' pointer.  So spawn cannot
> guarantee it doesn't point to unshared data.
> 
> -Steve

Bad. I tried to pass as an argument a pointer to an instance of a class - 
a this pointer. That didn't work.
July 18, 2011
Re: std.concurrency.spawn does not accept delegates
On Monday 18 July 2011 15:55:52 teo wrote:
> On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer wrote:
> > On Sun, 17 Jul 2011 15:29:02 -0400, teo <teo.ubuntu@yahoo.com> wrote:
> >> It looks like std.concurrency.spawn does not accept delegates. Is
> >> there
> >> any reason for that?
> > 
> > There is no type attached to the hidden 'this' pointer.  So spawn cannot
> > guarantee it doesn't point to unshared data.
> > 
> > -Steve
> 
> Bad. I tried to pass as an argument a pointer to an instance of a class -
> a this pointer. That didn't work.

Only stuff that's immutable or implicitly convertible immutable can be passed 
across threads using spawn and send. Otherwise, there's a risk of it ending up 
getting altered by both threads (or altered by one when the other one is using 
at it). Sometimes, that can be a bit restrictive (particularly when you _know_ 
that something isn't going to be altered by the thread sending it after its 
sent but the compiler doesn't), but it avoids all kinds of problems. If you 
want to send a class object across, then it needs to be immutable (which tends 
to be a bit of a pain to do for classes, since they need to have an immutable 
constructor, which is often a pain to do).

- Jonathan M Davis
July 18, 2011
Re: std.concurrency.spawn does not accept delegates
On Mon, 18 Jul 2011 18:06:46 +0200, Jonathan M Davis <jmdavisProg@gmx.com>  
wrote:

> On Monday 18 July 2011 15:55:52 teo wrote:
>> On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer wrote:
>> > On Sun, 17 Jul 2011 15:29:02 -0400, teo <teo.ubuntu@yahoo.com> wrote:
>> >> It looks like std.concurrency.spawn does not accept delegates. Is
>> >> there
>> >> any reason for that?
>> >
>> > There is no type attached to the hidden 'this' pointer.  So spawn  
>> cannot
>> > guarantee it doesn't point to unshared data.
>> >
>> > -Steve
>>
>> Bad. I tried to pass as an argument a pointer to an instance of a class  
>> -
>> a this pointer. That didn't work.
>
> Only stuff that's immutable or implicitly convertible immutable can be  
> passed
> across threads using spawn and send. Otherwise, there's a risk of it  
> ending up
> getting altered by both threads (or altered by one when the other one is  
> using
> at it). Sometimes, that can be a bit restrictive (particularly when you  
> _know_
> that something isn't going to be altered by the thread sending it after  
> its
> sent but the compiler doesn't), but it avoids all kinds of problems. If  
> you
> want to send a class object across, then it needs to be immutable (which  
> tends
> to be a bit of a pain to do for classes, since they need to have an  
> immutable
> constructor, which is often a pain to do).

It could be that assumeUnique should handle this, by transforming the
delegate into something spawn() and friends could handle.

Might be worth an enhancement request.


-- 
  Simen
July 18, 2011
Re: std.concurrency.spawn does not accept delegates
On 2011-07-18 10:54, Simen Kjaeraas wrote:
> On Mon, 18 Jul 2011 18:06:46 +0200, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > On Monday 18 July 2011 15:55:52 teo wrote:
> >> On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer wrote:
> >> > On Sun, 17 Jul 2011 15:29:02 -0400, teo <teo.ubuntu@yahoo.com> wrote:
> >> >> It looks like std.concurrency.spawn does not accept delegates. Is
> >> >> there
> >> >> any reason for that?
> >> > 
> >> > There is no type attached to the hidden 'this' pointer. So spawn
> >> 
> >> cannot
> >> 
> >> > guarantee it doesn't point to unshared data.
> >> > 
> >> > -Steve
> >> 
> >> Bad. I tried to pass as an argument a pointer to an instance of a class
> >> -
> >> a this pointer. That didn't work.
> > 
> > Only stuff that's immutable or implicitly convertible immutable can be
> > passed
> > across threads using spawn and send. Otherwise, there's a risk of it
> > ending up
> > getting altered by both threads (or altered by one when the other one is
> > using
> > at it). Sometimes, that can be a bit restrictive (particularly when you
> > _know_
> > that something isn't going to be altered by the thread sending it after
> > its
> > sent but the compiler doesn't), but it avoids all kinds of problems. If
> > you
> > want to send a class object across, then it needs to be immutable (which
> > tends
> > to be a bit of a pain to do for classes, since they need to have an
> > immutable
> > constructor, which is often a pain to do).
> 
> It could be that assumeUnique should handle this, by transforming the
> delegate into something spawn() and friends could handle.
> 
> Might be worth an enhancement request.

There have been discussions about how to do it in the past. Whether 
assumeUnique will work depends on whether casting to immutable(C) will work 
(where C is the class' type), and I don't know whether that cast will work or 
not. If it does, then assumeUnique will do it, since all it does is cast to 
immutable, but it's the sort of thing that requires language support. There 
_might_ be a way to solve the problem with some sort of Unique template that 
spawn and send knew about, but nothing of the sort has been done yet. But 
until a number of the issues with const and immutable in the compiler have 
been sorted out, that sort of thing would probably be problematic anyway.

- Jonathan M Davis
July 18, 2011
Re: std.concurrency.spawn does not accept delegates
On Mon, 18 Jul 2011 18:14:45 +0000, Jonathan M Davis wrote:

> On 2011-07-18 10:54, Simen Kjaeraas wrote:
>> On Mon, 18 Jul 2011 18:06:46 +0200, Jonathan M Davis
>> <jmdavisProg@gmx.com>
>> 
>> wrote:
>> > On Monday 18 July 2011 15:55:52 teo wrote:
>> >> On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer wrote:
>> >> > On Sun, 17 Jul 2011 15:29:02 -0400, teo <teo.ubuntu@yahoo.com>
>> >> > wrote:
>> >> >> It looks like std.concurrency.spawn does not accept delegates. Is
>> >> >> there
>> >> >> any reason for that?
>> >> > 
>> >> > There is no type attached to the hidden 'this' pointer. So spawn
>> >> 
>> >> cannot
>> >> 
>> >> > guarantee it doesn't point to unshared data.
>> >> > 
>> >> > -Steve
>> >> 
>> >> Bad. I tried to pass as an argument a pointer to an instance of a
>> >> class -
>> >> a this pointer. That didn't work.
>> > 
>> > Only stuff that's immutable or implicitly convertible immutable can
>> > be passed
>> > across threads using spawn and send. Otherwise, there's a risk of it
>> > ending up
>> > getting altered by both threads (or altered by one when the other one
>> > is using
>> > at it). Sometimes, that can be a bit restrictive (particularly when
>> > you _know_
>> > that something isn't going to be altered by the thread sending it
>> > after its
>> > sent but the compiler doesn't), but it avoids all kinds of problems.
>> > If you
>> > want to send a class object across, then it needs to be immutable
>> > (which tends
>> > to be a bit of a pain to do for classes, since they need to have an
>> > immutable
>> > constructor, which is often a pain to do).
>> 
>> It could be that assumeUnique should handle this, by transforming the
>> delegate into something spawn() and friends could handle.
>> 
>> Might be worth an enhancement request.
> 
> There have been discussions about how to do it in the past. Whether
> assumeUnique will work depends on whether casting to immutable(C) will
> work (where C is the class' type), and I don't know whether that cast
> will work or not. If it does, then assumeUnique will do it, since all it
> does is cast to immutable, but it's the sort of thing that requires
> language support. There _might_ be a way to solve the problem with some
> sort of Unique template that spawn and send knew about, but nothing of
> the sort has been done yet. But until a number of the issues with const
> and immutable in the compiler have been sorted out, that sort of thing
> would probably be problematic anyway.
> 
> - Jonathan M Davis

This is a bit too restrictive in my opinion. Only the shared data between 
two threads should be immutable. But the threads can access all sorts of 
mutable data as well. And in this case we are actually talking about the 
control function (or start routine) of a thread. As long as it's address 
is fixed within the memory of a process its usage for that purpose should 
be fine. Nobody is going to pass that address around. Am I missing 
anything here?
July 18, 2011
Re: std.concurrency.spawn does not accept delegates
On 2011-07-18 15:15, teo wrote:
> On Mon, 18 Jul 2011 18:14:45 +0000, Jonathan M Davis wrote:
> > On 2011-07-18 10:54, Simen Kjaeraas wrote:
> >> On Mon, 18 Jul 2011 18:06:46 +0200, Jonathan M Davis
> >> <jmdavisProg@gmx.com>
> >> 
> >> wrote:
> >> > On Monday 18 July 2011 15:55:52 teo wrote:
> >> >> On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer wrote:
> >> >> > On Sun, 17 Jul 2011 15:29:02 -0400, teo <teo.ubuntu@yahoo.com>
> >> >> > 
> >> >> > wrote:
> >> >> >> It looks like std.concurrency.spawn does not accept delegates. Is
> >> >> >> there
> >> >> >> any reason for that?
> >> >> > 
> >> >> > There is no type attached to the hidden 'this' pointer. So spawn
> >> >> 
> >> >> cannot
> >> >> 
> >> >> > guarantee it doesn't point to unshared data.
> >> >> > 
> >> >> > -Steve
> >> >> 
> >> >> Bad. I tried to pass as an argument a pointer to an instance of a
> >> >> class -
> >> >> a this pointer. That didn't work.
> >> > 
> >> > Only stuff that's immutable or implicitly convertible immutable can
> >> > be passed
> >> > across threads using spawn and send. Otherwise, there's a risk of it
> >> > ending up
> >> > getting altered by both threads (or altered by one when the other one
> >> > is using
> >> > at it). Sometimes, that can be a bit restrictive (particularly when
> >> > you _know_
> >> > that something isn't going to be altered by the thread sending it
> >> > after its
> >> > sent but the compiler doesn't), but it avoids all kinds of problems.
> >> > If you
> >> > want to send a class object across, then it needs to be immutable
> >> > (which tends
> >> > to be a bit of a pain to do for classes, since they need to have an
> >> > immutable
> >> > constructor, which is often a pain to do).
> >> 
> >> It could be that assumeUnique should handle this, by transforming the
> >> delegate into something spawn() and friends could handle.
> >> 
> >> Might be worth an enhancement request.
> > 
> > There have been discussions about how to do it in the past. Whether
> > assumeUnique will work depends on whether casting to immutable(C) will
> > work (where C is the class' type), and I don't know whether that cast
> > will work or not. If it does, then assumeUnique will do it, since all it
> > does is cast to immutable, but it's the sort of thing that requires
> > language support. There _might_ be a way to solve the problem with some
> > sort of Unique template that spawn and send knew about, but nothing of
> > the sort has been done yet. But until a number of the issues with const
> > and immutable in the compiler have been sorted out, that sort of thing
> > would probably be problematic anyway.
> > 
> > - Jonathan M Davis
> 
> This is a bit too restrictive in my opinion. Only the shared data between
> two threads should be immutable. But the threads can access all sorts of
> mutable data as well. And in this case we are actually talking about the
> control function (or start routine) of a thread. As long as it's address
> is fixed within the memory of a process its usage for that purpose should
> be fine. Nobody is going to pass that address around. Am I missing
> anything here?

When passing data between threads, it must be immutable. If it weren't, then 
you'd have to worry about mutexes and the like. Data is thread-local by 
default, so one thread does _not_ have access to the data in another thread 
unless it's shared. spawn starts a new thread with the data that it's given, 
and send allows you to send data to another thread, but if it's not immutable, 
then you're running into issues when multiple threads are dealing with mutabel 
data and could change it. And that's not allowed unless the data is shared - 
in which case there's no need for send, and you have to use mutexes or 
synchronized blocks to control access to it, ord you're going to have 
concurrency bugs.

- Jonathan M Davis
July 19, 2011
Re: std.concurrency.spawn does not accept delegates
On Mon, 18 Jul 2011 18:39:01 -0400, Jonathan M Davis <jmdavisProg@gmx.com>  
wrote:

> On 2011-07-18 15:15, teo wrote:
>> On Mon, 18 Jul 2011 18:14:45 +0000, Jonathan M Davis wrote:
>> > On 2011-07-18 10:54, Simen Kjaeraas wrote:
>> >> On Mon, 18 Jul 2011 18:06:46 +0200, Jonathan M Davis
>> >> <jmdavisProg@gmx.com>
>> >>
>> >> wrote:
>> >> > On Monday 18 July 2011 15:55:52 teo wrote:
>> >> >> On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer wrote:
>> >> >> > On Sun, 17 Jul 2011 15:29:02 -0400, teo <teo.ubuntu@yahoo.com>
>> >> >> >
>> >> >> > wrote:
>> >> >> >> It looks like std.concurrency.spawn does not accept delegates.  
>> Is
>> >> >> >> there
>> >> >> >> any reason for that?
>> >> >> >
>> >> >> > There is no type attached to the hidden 'this' pointer. So spawn
>> >> >>
>> >> >> cannot
>> >> >>
>> >> >> > guarantee it doesn't point to unshared data.
>> >> >> >
>> >> >> > -Steve
>> >> >>
>> >> >> Bad. I tried to pass as an argument a pointer to an instance of a
>> >> >> class -
>> >> >> a this pointer. That didn't work.
>> >> >
>> >> > Only stuff that's immutable or implicitly convertible immutable can
>> >> > be passed
>> >> > across threads using spawn and send. Otherwise, there's a risk of  
>> it
>> >> > ending up
>> >> > getting altered by both threads (or altered by one when the other  
>> one
>> >> > is using
>> >> > at it). Sometimes, that can be a bit restrictive (particularly when
>> >> > you _know_
>> >> > that something isn't going to be altered by the thread sending it
>> >> > after its
>> >> > sent but the compiler doesn't), but it avoids all kinds of  
>> problems.
>> >> > If you
>> >> > want to send a class object across, then it needs to be immutable
>> >> > (which tends
>> >> > to be a bit of a pain to do for classes, since they need to have an
>> >> > immutable
>> >> > constructor, which is often a pain to do).
>> >>
>> >> It could be that assumeUnique should handle this, by transforming the
>> >> delegate into something spawn() and friends could handle.
>> >>
>> >> Might be worth an enhancement request.
>> >
>> > There have been discussions about how to do it in the past. Whether
>> > assumeUnique will work depends on whether casting to immutable(C) will
>> > work (where C is the class' type), and I don't know whether that cast
>> > will work or not. If it does, then assumeUnique will do it, since all  
>> it
>> > does is cast to immutable, but it's the sort of thing that requires
>> > language support. There _might_ be a way to solve the problem with  
>> some
>> > sort of Unique template that spawn and send knew about, but nothing of
>> > the sort has been done yet. But until a number of the issues with  
>> const
>> > and immutable in the compiler have been sorted out, that sort of thing
>> > would probably be problematic anyway.
>> >
>> > - Jonathan M Davis
>>
>> This is a bit too restrictive in my opinion. Only the shared data  
>> between
>> two threads should be immutable. But the threads can access all sorts of
>> mutable data as well. And in this case we are actually talking about the
>> control function (or start routine) of a thread. As long as it's address
>> is fixed within the memory of a process its usage for that purpose  
>> should
>> be fine. Nobody is going to pass that address around. Am I missing
>> anything here?
>
> When passing data between threads, it must be immutable.

I have to jump in and correct you, nobody else has.

You can also pass data marked as shared.

A solution could be to cast the class as shared, pass it, then cast it  
back to unshared (ensuring you don't access the class from the originator  
anymore).

This is not a compiler-enforced solution, but it gets the job done.  But  
there is risk of concurrency errors if you don't do it right.  My  
recommendation is to isolate the parts that create and pass the shared  
data.

-Steve
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home