Greets, On Fri 12 May 2017 16:13, Derek Upham <s...@blarg.net> writes:
> Andy Wingo <wi...@pobox.com> writes: > >> scm_join_thread isn't actually implemented in terms of >> scm_i_pthread_join any more. Probably that's what's going wrong here -- >> and probably that should be fixed to ensure that we actually join the >> thread. (Otherwise it would be a memory leak too AFAIU.) Bcc'ing >> bug-guile to create a bug for that. > > I noticed that scm_join_thread was calling back into Scheme-land. Are these > statements all correct? > > - We are using call-with-new-thread underneath the hood. Underneath the hood of what? :) > - call-with-new-thread is documented to return a Scheme object from a > thunk/handler. Any underlying pthreads should be implementation > details. Correct. In practice call-with-new-thread will create a pthread but I can imagine circumstances in which it might (in the future) spawn an auxiliary pthread for some reason, and I wouldn't want to rule that out. > - The spawned thread sends the Scheme object to the condition variable > as soon as the user thunk exits. Any number of operations can happen > afterwards; the thread is still running in Scheme-land at this point, > in call-with-new-thread’s wrapping thunk. > - join-thread waits on the condition variable only. These are implementation details. They are correct but probably the implementation should change to do the scm_i_pthread_join and we should guarantee that after the join, the thread is really dead. This is bug 26858. > So at the end of join-thread we need to add a call to > scm_i_pthread_join (which we implement in threads.c) to ensure that > the pthread is completely gone before that join-thread returns. Is > that accurate? Well... yes, but we have to ensure that we call scm_i_pthread_join at most once. I think calling pthread_join twice on a thread is undefined. So there are some gnarlies here. Need to fix this. > Unfortunately, I think the GC threads are going to end up being > immovable objects in the path to full process-form support. You can disable marker threads with the GC_MARKERS environment variable, and the finalization thread should come and go as needed. Probably this is not a blocker from your POV. Signal handling is probably the most serious issue; perhaps we can avoid the thread somehow, since we handle signals asynchronously anyway.. Andy
