Re: Concurrency via isolated process/thread

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> AFAIU, we can then raise a flag that GC is necessary, so that other
>> threads will stop next time they reach maybe_gc, until GC is complete.
>
> What if even one of those other threads never calls maybe_gc?  This can
> easily happen if they are blocked by a long running operation (domain
> name resolution comes to mind) and will result in all threads waiting
> for it to complete, defeating the purpose of having threads in the first
> place.

Good point.
Maybe something similar to how thread-yield is triggered by
`accept-process-output' - add extra maybe_gc() to process code as
necessary.

> TRT on GNU and other Mach based systems (OSF/1, OS X, etc) is to suspend
> all other threads using `thread_suspend' and then run GC from whichever
> thread is the first to discover that the consing threshold has been
> exceeded.  Unix systems typically provide other platform specific
> functions to suspend threads or LWPs.
>
> As a consequence of this approach, GC can take place even if those other
> threads hold pointers to relocatable string data and buffer text.  I've
> experimentally verified that this is rare, and that not compacting
> string blocks which are referenced from the stack or in registers
> doesn't significantly affect string data fragmentation.

Sounds not 100% reliable.
May it be possible to restart blocking operation if GC is triggered in
the middle of it?

What I have in mind is something similar to

(setq sucess nil)
(while (not success)
  (while-no-input
    (do-staff-that-knows-it-can-be-restarted-sometimes)
    (setq sucess t)))

but for low-level code that requires object locks.    

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>