I use this simple code to run something in separate thread:

class X : Thread {
public this() {
super(&(this.go));
}

public ~this() {
printf("Thread deleted\n");
}

public int go() {
printf("Thread started\n");
delete this;
return 0;
}
}

int main(char[][] args) {
X x = new X;
x.start();
return 0;
}

1) If I cut "delete this;", than X.~this is not called at all, but I think it
should.
2) In both cases, after this thread ends, Thread.getAll() returns 2 elements -
pointer to the main thread and zero pointer.
3) If I start new threads in loop (with delay of course), memory leak occurs -
program gets 8K memory per iteration, and its virtual size grows up much more
faster (about 8M per iteration!!!).

I think all this is caused by Phobos library.
Does anybody know if I am right or not?
If I make changes in std.thread, can I commit them into project? I think D
project needs normal community, something like bugzilla, not this primitive
"forum". =(

Vladimir Kulev wrote:
> I use this simple code to run something in separate thread:
> 
> class X : Thread {
> public this() {
> super(&(this.go));
> }
> 
> public ~this() {
> printf("Thread deleted\n");
> }
> 
> public int go() {
> printf("Thread started\n");

[snip]

> return 0;
> }
> }
> 
> int main(char[][] args) {
> X x = new X;
> x.start();

x.waitFor();

> return 0;
> }
> 
> 1) If I cut "delete this;", than X.~this is not called at all, but I think it
> should.

Dtors are not guaranteed to be called in GCed languages.  However, it may be that the dtor is being called and you just aren't seeing it because it's occurring after main exits.  Try the waitFor line above.

> 2) In both cases, after this thread ends, Thread.getAll() returns 2 elements -
> pointer to the main thread and zero pointer.

This is a quirk of the Phobos implementation.  It was chosen so as to avoid the need for a mutex around the internal thread list.  Personally, I don't think it is a worthwhile tradeoff, but...

> 3) If I start new threads in loop (with delay of course), memory leak occurs -
> program gets 8K memory per iteration, and its virtual size grows up much more
> faster (about 8M per iteration!!!).

Windows allocates a good bit of memory for each thread as it is created--this may be what you're seeing.  I would be surprised if this were an artifact of how Phobos is creating threads.

> I think all this is caused by Phobos library.
> Does anybody know if I am right or not?

See above.

> If I make changes in std.thread, can I commit them into project? I think D
> project needs normal community, something like bugzilla, not this primitive
> "forum". =(

You might be interested in the Ares project:

http://www.dsource.org/projects/ares/
http://trac.dsource.org/projects/ares/ (temporary Trac page)

Please note that Posix support is a bit thin at the moment, so it won't run out of the box on non-Windows systems.  This will change before too terribly long.


Sean

In article <dqg763$1b0v$1@digitaldaemon.com>, Vladimir Kulev says...
>I think all this is caused by Phobos library.
>Does anybody know if I am right or not?
>If I make changes in std.thread, can I commit them into project? I think D
>project needs normal community, something like bugzilla, not this primitive
>"forum". =(
>

I totally agree! I've been grumbling this to myself for about a year. I don't understand why Walter prefers to keep track of bugs in an NNTP (getting a little old) newsgroup. speaking of which you should post this in digitalmars.D.bugs.

Chris

Chris Lajoie wrote:
> In article <dqg763$1b0v$1@digitaldaemon.com>, Vladimir Kulev says...
> 
>>I think all this is caused by Phobos library.
>>Does anybody know if I am right or not?
>>If I make changes in std.thread, can I commit them into project? I think D
>>project needs normal community, something like bugzilla, not this primitive
>>"forum". =(
>>
> 
> 
> I totally agree! I've been grumbling this to myself for about a year. I don't
> understand why Walter prefers to keep track of bugs in an NNTP (getting a little
> old) newsgroup. speaking of which you should post this in digitalmars.D.bugs.
> 

 Not taking sides here, but there's a question I've been (sort of) brewing on, for quite a while.

About threading: there are (obviously) situations were one would like "preemptive multitasking", or whatever serves close enough to such a purpose.

Then there are situations where one would like "virtual multitasking".

(The latter being all the situations where the program has to tend to "several 'same-time' 'thingies'" like they'd _all_ be served Instantaneously.)

----

Ok, we've got "Pre-Emptive Multitasking" on one hand, and "Co-operative Multitasking" on the other.

Most of the implementations of _both_ are (either) over-diligent _and_ over-theoretical, or, 'practical' (unfortunately meaning, only that the Implementors were too lazy to properly Read the Book).

----

Instead of these two issues, we might turn to the factual problems at hand. Like: "exactly where do you need one (or the other). Do you actually _understand_ the difference (and the implications thereof), between pre-emptive and co-operative? And, do you really claim, that each place you invoke either, is Genuinely a Case for One or the Other?

----

((Now, still witholding my personal opinion (being, that pthreads are overkill in _most_ regular thread situations, _and_ [application level] co-operative multitasking is (( put your own derogatory attribute here: [brittle, inefficient, insufficient, hard to predict, not-grand, non-professional, un-cool])), there arises a question: between the folks who actually _do_ think with their own brains, is there an avalanche going on, towards something more predictable, more easier to handle, more logical to "grok", more _effective_ or _efficient_ (considering the "whole". ??))

Georg Wrede wrote:
> 
> 
> Chris Lajoie wrote:
>> In article <dqg763$1b0v$1@digitaldaemon.com>, Vladimir Kulev says...
>>
>>> I think all this is caused by Phobos library.
>>> Does anybody know if I am right or not?
>>> If I make changes in std.thread, can I commit them into project? I think D
>>> project needs normal community, something like bugzilla, not this primitive
>>> "forum". =(
>>>
>>
>>
>> I totally agree! I've been grumbling this to myself for about a year. I don't
>> understand why Walter prefers to keep track of bugs in an NNTP (getting a little
>> old) newsgroup. speaking of which you should post this in digitalmars.D.bugs.
>>
> 
>  Not taking sides here, but there's a question I've been (sort of) brewing on, for quite a while.
> 
> About threading: there are (obviously) situations were one would like "preemptive multitasking", or whatever serves close enough to such a purpose.
> 
> Then there are situations where one would like "virtual multitasking".
> 
> (The latter being all the situations where the program has to tend to "several 'same-time' 'thingies'" like they'd _all_ be served Instantaneously.)
> 
> ----
> 
> Ok, we've got "Pre-Emptive Multitasking" on one hand, and "Co-operative Multitasking" on the other.
> 
> Most of the implementations of _both_ are (either) over-diligent _and_ over-theoretical, or, 'practical' (unfortunately meaning, only that the Implementors were too lazy to properly Read the Book).
> 
> ----
> 
> Instead of these two issues, we might turn to the factual problems at hand. Like: "exactly where do you need one (or the other). Do you actually _understand_ the difference (and the implications thereof), between pre-emptive and co-operative? And, do you really claim, that each place you invoke either, is Genuinely a Case for One or the Other?
> 
> ----
> 
> ((Now, still witholding my personal opinion (being, that pthreads are overkill in _most_ regular thread situations, _and_ [application level] co-operative multitasking is (( put your own derogatory attribute here: [brittle, inefficient, insufficient, hard to predict, not-grand, non-professional, un-cool])), there arises a question: between the folks who actually _do_ think with their own brains, is there an avalanche going on, towards something more predictable, more easier to handle, more logical to "grok", more _effective_ or _efficient_ (considering the "whole". ??))

This was just posted to c.p.t:

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/6a7bf9e15c125428/93d9c747b3248e0f#93d9c747b3248e0f


Sean