www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bartosz asks =?windows-1252?Q?What=92s_Wrong_with_the_Th?=

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.reddit.com/r/programming/comments/8z3wm/whats_wrong_with_the_thread_object/
Jul 07 2009
parent reply Bartosz Milewski <bartosz-nospam relisoft.com> writes:
Walter Bright Wrote:

 http://www.reddit.com/r/programming/comments/8z3wm/whats_wrong_with_the_thread_object/

The bottom line of this post is that the current Thread object in D should be abandoned and replaced by a more primitive "spawn" function. If there are no serious objections, we are going to proceed with the rewrite.
Jul 08 2009
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 08 Jul 2009 19:34:51 -0400, Bartosz Milewski  
<bartosz-nospam relisoft.com> wrote:

 Walter Bright Wrote:

 http://www.reddit.com/r/programming/comments/8z3wm/whats_wrong_with_the_thread_object/

The bottom line of this post is that the current Thread object in D should be abandoned and replaced by a more primitive "spawn" function. If there are no serious objections, we are going to proceed with the rewrite.

I'd be interested to know if Sean has seen this. What you lose in not having a primitive thread be a class is that it's more difficult to hook thread runtime events. However, looking at the thread class, nothing is hookable through overriding except for run, which means you have a very valid point. In fact, you could probably implement the current Thread on top of your spawn function. I think it would be a good boilerplate thing, since a thread's functionality is often well encapsulated as an object. Not to mention existing code (and lots of it!). -Steve
Jul 08 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Wed, 08 Jul 2009 19:34:51 -0400, Bartosz Milewski
 <bartosz-nospam relisoft.com> wrote:
 Walter Bright Wrote:

 http://www.reddit.com/r/programming/comments/8z3wm/whats_wrong_with_the_thread_object/

The bottom line of this post is that the current Thread object in D should be abandoned and replaced by a more primitive "spawn" function. If there are no serious objections, we are going to proceed with the rewrite.

What you lose in not having a primitive thread be a class is that it's more difficult to hook thread runtime events. However, looking at the thread class, nothing is hookable through overriding except for run, which means you have a very valid point.

Even run isn't supposed to be overridable, as it's a private method. This works only because of a compiler bug.
 In fact, you could probably implement the current Thread on top of your
 spawn function.  I think it would be a good boilerplate thing, since a
 thread's functionality is often well encapsulated as an object.  Not to
 mention existing code (and lots of it!).

It would be trivial to implement spawn on top of the Thread object. And the reverse would work as well, though it would be less practical. After all, some data must be used to represent a thread even with the spawn model, and it would be silly to graft a thread abstraction a few layers above this.
Jul 09 2009
parent Bartosz Milewski <bartosz-nospam relisoft.com> writes:
Sean Kelly Wrote:
 
 It would be trivial to implement spawn on top of the Thread object.

Not so trivial, as I would like the spawn function to be a variadic template.
 And
 the reverse would work as well, though it would be less practical.  After
 all, some data must be used to represent a thread even with the spawn
 model, and it would be silly to graft a thread abstraction a few layers
 above this.

I didn't discuss the details of spawn, but I see it as returning a ThreadHandle struct holding the ID and providing methods that operate on the thread--essentially all the Thread methods except run.
Jul 09 2009
prev sibling next sibling parent Sjoerd van Leent <svanleent gmail.com> writes:
Bartosz Milewski Wrote:

 Walter Bright Wrote:
 
 http://www.reddit.com/r/programming/comments/8z3wm/whats_wrong_with_the_thread_object/

The bottom line of this post is that the current Thread object in D should be abandoned and replaced by a more primitive "spawn" function. If there are no serious objections, we are going to proceed with the rewrite.

If you'd like, perhaps a nice template that would be able to curry would be nice. So, for example (hypothethically): void my_func(int a, int b) { writefln("%d", a+b); } int main(char[][] args) { auto thread << spawn!(my_func, 8); thread.run(9); while(thread.running()) { yield(); } return 0; } output: 17
Jul 09 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 09 Jul 2009 08:48:45 -0400, Sean Kelly <sean invisibleduck.org>  
wrote:

 Even run isn't supposed to be overridable, as it's a private method.   
 This
 works only because of a compiler bug.

whoa! I didn't realize that! Why would you ever inherit from Thread (even as the doc says, call super(&run) in the constructor)? That is, should Thread really be a class, since all it does is contain context data?
 It would be trivial to implement spawn on top of the Thread object.  And
 the reverse would work as well, though it would be less practical.  After
 all, some data must be used to represent a thread even with the spawn
 model, and it would be silly to graft a thread abstraction a few layers
 above this.

The data is already a reference (i.e. phtread_thread_t is a reference as far as I know), so you are not actually containing the data, just a pointer to the data. This could be easily returned from spawn. As far as the context data that's *passed* to the thread that the user cares about, I don't think it makes a huge difference either way. One other thing to note about changing the thread model -- It breaks future Tango (>=D2) compatibility, I'm not sure the Tango team wants to move to a different thread implementation. -Steve
Jul 09 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 09 Jul 2009 11:36:05 -0400, Bartosz Milewski  
<bartosz-nospam relisoft.com> wrote:

 Sean Kelly Wrote:

 It would be trivial to implement spawn on top of the Thread object.

Not so trivial, as I would like the spawn function to be a variadic template.

How is that not trivial? Or at least less trivial than implementing Thread on top of spawn? All Thread does is abstract the OS' threading mechanism, which you have to deal with anyway. As Sean pointed out, it doesn't even require you to inherit from Thread (as I thought previously) to make a new thread.
 And
 the reverse would work as well, though it would be less practical.   
 After
 all, some data must be used to represent a thread even with the spawn
 model, and it would be silly to graft a thread abstraction a few layers
 above this.

I didn't discuss the details of spawn, but I see it as returning a ThreadHandle struct holding the ID and providing methods that operate on the thread--essentially all the Thread methods except run.

Where do the static functions go? i.e. sleep, opApply, etc. -Steve
Jul 09 2009