digitalmars.D - Bartosz asks =?windows-1252?Q?What=92s_Wrong_with_the_Th?=
- Walter Bright (1/1) Jul 07 2009 http://www.reddit.com/r/programming/comments/8z3wm/whats_wrong_with_the_...
- Bartosz Milewski (2/3) Jul 08 2009 The bottom line of this post is that the current Thread object in D shou...
- Steven Schveighoffer (12/18) Jul 08 2009 I'd be interested to know if Sean has seen this.
- Sean Kelly (8/27) Jul 09 2009 Even run isn't supposed to be overridable, as it's a private method. Th...
- Bartosz Milewski (4/10) Jul 09 2009 Not so trivial, as I would like the spawn function to be a variadic temp...
- Steven Schveighoffer (9/22) Jul 09 2009 How is that not trivial? Or at least less trivial than implementing
- Steven Schveighoffer (14/22) Jul 09 2009 whoa! I didn't realize that! Why would you ever inherit from Thread
- Sjoerd van Leent (18/23) Jul 09 2009 If you'd like, perhaps a nice template that would be able to curry would...
http://www.reddit.com/r/programming/comments/8z3wm/whats_wrong_with_the_thread_object/
Jul 07 2009
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
On Wed, 08 Jul 2009 19:34:51 -0400, Bartosz Milewski <bartosz-nospam relisoft.com> wrote:Walter Bright Wrote: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!). -Stevehttp://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
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s articleOn Wed, 08 Jul 2009 19:34:51 -0400, Bartosz Milewski <bartosz-nospam relisoft.com> wrote:Even run isn't supposed to be overridable, as it's a private method. This works only because of a compiler bug.Walter Bright Wrote: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.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.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
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
On Thu, 09 Jul 2009 11:36:05 -0400, Bartosz Milewski <bartosz-nospam relisoft.com> wrote:Sean Kelly Wrote: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.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.Where do the static functions go? i.e. sleep, opApply, etc. -SteveAnd 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
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
Bartosz Milewski Wrote:Walter Bright Wrote: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: 17http://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 09 2009