@mflatt, I see in core.sls that #%app is exported, but when I try to export #%active-threads in the same manner I get a missing definition error missing definition for export \x23;%active-threads Do you know how to fix this or should I export a function that just calls #%active-threads?

Do you mean #%$active-threads? The expression #%$active-threads in Chez Scheme is not a reference to a variable named #%$active-threads. Instead, #% is a prefix that means access a primitive, and $active-threads is the name of the primitive. I think you want to define and export an active-pthreads function that returns the value of the $active-threads primitive by using #%$active-threads.

Okay thanks, I thought #%active-threads was a function, based on using it in the chez command line

@mflatt, I have updated the pull request

I can merge, but thinking about the patch more: I guess the non-(= 0 (get-thread-id)) branch in collect-garbage is meant to allow a future computation to call collect-garbage – but multiple futures could set collect-garbage-pending? at the same time, and they might set it to different things, in which case one of them is lost. Also, the future will proceed without actually collecting. I wonder whether collect-garbage should just be a barricade in a future.

@mflatt won’t supporting collect-garbage in places require the same code?

Places will need more, I expect, since there will be multiple Racket-thread schedulers running. Certainly, (collect-garbage) shouldn’t return without GCing in a place other than the original one. With this implementation, if a future thread is running while the main thread is sleeping, will a GC ever happen? Or is that not a problem because the main thread still busy-waits while a future is running?

>but multiple futures could set collect-garbage-pending? at the same time, and they might set it to different things, in which case one of them is lost.

The parameter could store a list so none of them is lost

>Also, the future will proceed without actually collecting. I wonder whether collect-garbage should just be a barricade in a future.

Does racket guarantee that a garbage collection will happen immediately?

Yes

Well then I guess this method would not work since it would break the guarantees

Requests an immediate garbage collection or requests a garbage-collection mode, depending on request: this makes it sound like it might not happen immediately in all cases?

perhaps the call to collect-garbage in a future should be treated the way “sync” future operations are currently treated in the racket6 VM

so that the requesting future waits for the main thread to execute the collection, but then resumes

That seems doable. What I’m envisioning is that insteading of having the pthread halt in the future when the main pthread starts collecting garbage, it would just halt immediately and wait

I guess the docs are not clear, but “requests a garbage-collection mode” is meant to be about 'incremental

@spall I was thinking that just the future that requsted the collection could be descheduled until the collection finished

That would probably work as well, just be slightly more complicated.

I think it depends on how long the system has to wait for the main thread to do the gc. If the main thread does the gc very quickly then halting a pthread immediately probably wont have a bad performance effect.

I’m going to go ahead and implement @samth’s suggestion.

@mflatt. I have updated the pull request again.

oh I’m sorry I meant to squash the 2nd commit but did not

I posted a comment, but I’m willing to just merge if you don’t think the suggestions are worth changes

I just assumed order was important for the garbage collection, but if it isn’t I can make it a stack rather than a queue?

And it being a parameter isn’t really serving a purpose so I can change that.

I think a stack is fine. (There are other things that could be done, such as signaling all futures that made the same request on one go – but if many futures are requesting GCs, then something bigger has gone wrong in an application’s attempt to gain parallelism.)

@mflatt, I think I have made the final changes to the gc pull request if you would like to review them

Thanks! I’ll merge later today, although the ?s on the end of the box variable names bug me, since booleans aren’t involved. I’m also not sure why some names are prefixed with chez:, but ok.

originally the variable was meant to be just #t or #f

And maybe this is due to my own misunderstanding, but the chez: is put on the front of things so naming collisions don’t happen in chez .sls files; maybe its unnecessary in this case

I do use chez: to avoid conflicts, but only for bindings to the normal Chez Scheme values

wouldn’t there be a collision in thread.sls?

compiled/thread.scm would define collect-garbage-pending-major? and it would have also been included from core?

Yes, but I wouldn’t use chez: as the disambiguator

what should be used insted?

(Actually, I’m not clear where the conflict would be for these names, but I can imagine there might be one.)

I think core: is a good prefix for things that originate from “core.sls”

oh maybe you are right, maybe they are just usages and not definitions

they’re in a define-values form