You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 1, 2020. It is now read-only.
Hi @janvorli.
Is there any progress on this, or would it be possible to work around the hijacking of threads? Right now a process on OSX/Unix will crash once the GC starts to suspend the threads, since it eventually calls PalHijack.
@christianscheuer I am sorry for the late response, I had vacation for the last two weeks. I am glad @jkotas has provided a quick workaround for that. I have worked on implementing the hijacking in the past, but then I've realized that there are some other necessary changes that needed to be done first in order to make the hijacking work. Also, the GC was not working at that point, so there was no way to verify the change.
But those prerequisities are now in, so I can finish the hijacking work.
Hi @janvorli. Thank you for getting back to me, and yes the workaround definitely helps a lot. Looking forward to seeing how you will implement this, given the limitations of the Unix platform wrt. thread suspension.
The first test case in #6780 seems to be deadlocking because of missing GC poll or asynchronous loop hijack mechanism. See #6780 (comment). I'll go ahead and resolve that issue with a fix for a different issue that was also reported there.
Thread hijacking is necessary e.g. for GC stack walking.
The text was updated successfully, but these errors were encountered: