• chrisj (5/5) Dec 15 2006 Can a low level thread interupt the GC and run ok as long as it doesnt u...
• Sean Kelly (9/12) Dec 15 2006 Are you asking whether it's safe to suspend the GC during a cleanup and
• chrisj (11/22) Dec 16 2006 Say you have a soundcard in/out or somthing like.. which gets called via...
• chrisj (2/27) Dec 16 2006
• Jarrett Billingsley (6/14) Dec 16 2006 This also implies another way to have code run while the GC is running -...
• chrisj (3/14) Dec 16 2006 How hard would it be to stop such a thread buggering up the GC?
• Jarrett Billingsley (9/15) Dec 16 2006 I guess just not using the GC? I.e. always using malloc/free, or no dyn...
• Sean Kelly (4/20) Dec 16 2006 It shouldn't be the sole owner of GCed memory or the memory may
• Frits van Bommel (8/13) Dec 16 2006 Until a moving collector appears on the scene...

"chrisj" <a b.c> writes:

Can a low level thread interupt the GC and run ok as long as it doesnt use 
any GC related features? (Only referances memory not from the GC pool and 
such like)

thanks,

chris 

Sean Kelly <sean f4.ca> writes:

chrisj wrote:
 Can a low level thread interupt the GC and run ok as long as it doesnt use 
 any GC related features? (Only referances memory not from the GC pool and 
 such like)

Are you asking whether it's safe to suspend the GC during a cleanup and 
then go do something else?  If so, then my answer is a very tenative 
"yes."  The GC suspends all threads it knows about during a collection 
(ie. all instances of std.thread.Thread) so each of these threads is 
frozen at some point of execution.  They could own mutexes, etc.  So any 
operation that may involve shared state information risks deadlocking 
the app.  In short, yes it's possible but you need to be very careful :-)


Sean

"chrisj" <a b.c> writes:

"Sean Kelly" <sean f4.ca> wrote in message 
news:elvfpr$1l8j$1 digitaldaemon.com...
 chrisj wrote:
 Can a low level thread interupt the GC and run ok as long as it doesnt 
 use any GC related features? (Only referances memory not from the GC pool 
 and such like)

 Are you asking whether it's safe to suspend the GC during a cleanup and 
 then go do something else?  If so, then my answer is a very tenative 
 "yes."  The GC suspends all threads it knows about during a collection 
 (ie. all instances of std.thread.Thread) so each of these threads is 
 frozen at some point of execution.  They could own mutexes, etc.  So any 
 operation that may involve shared state information risks deadlocking the 
 app.  In short, yes it's possible but you need to be very careful :-)

Say you have a soundcard in/out or somthing like.. which gets called via a 
callback from the driver or from windows, or even from another application. 
So the thread is not one actualy created by the D app... can the callback 
run as long as it doesnt use any features that will affect the GCed memory 
pool? Actually from what you say above it seems the GC cannot stop a 
callback from a thread it didnt create.. so the only option would be to make 
sure such a callback didnt affect the GC?

thanks,

chris 

"chrisj" <a b.c> writes:

"chrisj" <a b.c> wrote in message news:em12ih$6lk$1 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message 
 news:elvfpr$1l8j$1 digitaldaemon.com...
 chrisj wrote:
 Can a low level thread interupt the GC and run ok as long as it doesnt 
 use any GC related features? (Only referances memory not from the GC 
 pool and such like)

 Are you asking whether it's safe to suspend the GC during a cleanup and 
 then go do something else?  If so, then my answer is a very tenative 
 "yes."  The GC suspends all threads it knows about during a collection 
 (ie. all instances of std.thread.Thread) so each of these threads is 
 frozen at some point of execution.  They could own mutexes, etc.  So any 
 operation that may involve shared state information risks deadlocking the 
 app.  In short, yes it's possible but you need to be very careful :-)

 Say you have a soundcard in/out or somthing like.. which gets called via a 
 callback from the driver or from windows, or even from another 
 application. So the thread is not one actualy created by the D app... can 
 the callback run as long as it doesnt use any features that will affect 
 the GCed memory pool? Actually from what you say above it seems the GC 
 cannot stop a

Sorry should read the "GC cannot stop one that the D RTL didnt create"

 callback from a thread it didnt create.. so the only option would be to 
 make sure such a callback didnt affect the GC?

 thanks,

 chris
 

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Sean Kelly" <sean f4.ca> wrote in message 
news:elvfpr$1l8j$1 digitaldaemon.com...

 Are you asking whether it's safe to suspend the GC during a cleanup and 
 then go do something else?  If so, then my answer is a very tenative 
 "yes."  The GC suspends all threads it knows about during a collection 
 (ie. all instances of std.thread.Thread) so each of these threads is 
 frozen at some point of execution.

This also implies another way to have code run while the GC is running -- if 
you create a thread without using std.thread, the GC won't know about it and 
won't stop it during the collection.  So it can go ahead and run while the 
GC is doing its thing.

 They could own mutexes, etc.  So any operation that may involve shared 
 state information risks deadlocking the app.  In short, yes it's possible 
 but you need to be very careful :-) 

"chrisj" <a b.c> writes:

"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:em12j3$6ls$1 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message 
 news:elvfpr$1l8j$1 digitaldaemon.com...

 Are you asking whether it's safe to suspend the GC during a cleanup and 
 then go do something else?  If so, then my answer is a very tenative 
 "yes."  The GC suspends all threads it knows about during a collection 
 (ie. all instances of std.thread.Thread) so each of these threads is 
 frozen at some point of execution.

 This also implies another way to have code run while the GC is running --  
 if you create a thread without using std.thread, the GC won't know about 
 it and won't stop it during the collection.  So it can go ahead and run 
 while the GC is doing its thing.

How hard would it be to stop such a thread buggering up the GC? 

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"chrisj" <a b.c> wrote in message news:em12um$6ut$1 digitaldaemon.com...
 This also implies another way to have code run while the GC is running --  
 if you create a thread without using std.thread, the GC won't know about 
 it and won't stop it during the collection.  So it can go ahead and run 
 while the GC is doing its thing.

 How hard would it be to stop such a thread buggering up the GC?

I guess just not using the GC?  I.e. always using malloc/free, or no dynamic 
memory allocations at all?  And I suppose it'd also be a good idea not to 
touch memory that was allocated by the GC either.  So what you'd have to do 
is have a non-GC section of your program handled by that thread alone, and 
it wouldn't touch anything else.  Then your main GC'ed program would be able 
to look at the data held by the non-GC segment in order to update itself.

I don't know if this is all right.  I don't really have much experience with 
multithreaded programming, let alone those with non-GC parts. 

Sean Kelly <sean f4.ca> writes:

chrisj wrote:
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:em12j3$6ls$1 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message 
 news:elvfpr$1l8j$1 digitaldaemon.com...

 Are you asking whether it's safe to suspend the GC during a cleanup and 
 then go do something else?  If so, then my answer is a very tenative 
 "yes."  The GC suspends all threads it knows about during a collection 
 (ie. all instances of std.thread.Thread) so each of these threads is 
 frozen at some point of execution.

 This also implies another way to have code run while the GC is running --  
 if you create a thread without using std.thread, the GC won't know about 
 it and won't stop it during the collection.  So it can go ahead and run 
 while the GC is doing its thing.

 
 How hard would it be to stop such a thread buggering up the GC? 

It shouldn't be the sole owner of GCed memory or the memory may 
disappear out from under it.  Beyond that, it should be fine.


Sean

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Sean Kelly wrote:
 chrisj wrote:
 How hard would it be to stop such a thread buggering up the GC? 

 
 It shouldn't be the sole owner of GCed memory or the memory may 
 disappear out from under it.  Beyond that, it should be fine.

Until a moving collector appears on the scene...
Since such a collector should be perfectly legal according to the spec, 
such a thread basically can't use any GC-allocated memory at all without 
invoking undefined behavior.
However as far as it concerns current implementations I'm aware of 
you're correct; undefined behavior has the unfortunate property that it 
may mean "it does exactly what you'd expect it to do".