[erlang-questions] Suspending Erlang Processes

[Rickard Green]

On Wed, Oct 2, 2019 at 8:41 AM Duncan Paul Attard <
duncan.attard.01@REDACTED> wrote:

> Thanks for the explanation and for pointing the bug out. So it seems to me
> that there is no way to stop ‘receive’ trace events from being generated,
> despite the use of suspend. I guess this stems out from the asynchronous
> nature of the actor model.
>
> The language was designed with other communication primitives intended for
> use. Suspend/Resume was explicitly introduced for debugging purposes only,
> and not for usage by ordinary Erlang programs. They will most likely not
> disappear, but debug functionality in general are not treated as carefully
> by us at OTP as other ordinary functionality with regards to compatibility,
> etc. We for example removed the automatic deadlock prevention in
> suspend_process() that existed prior to erts 10.0 due to performance
> reasons.
>
>
> I understand and do agree that synchronisation in Erlang, and in general,
> the actor model is modelled via message exchanges only, and that utilising
> other primitives such as suspend and resume does not adhere to this model.
>
> Yet, in my particular use case (runtime verification), I am restricting
> myself to systems/processes that *cannot* be instrumented with additional
> instructions (in this case, receive clauses) so as to block their execution
> at specific points. Thus, the only way left to me would be to suspend a
> process whilst it is executing, *without* my having the knowledge of what
> instruction the process in question is executing. To give you a bit of
> context, I am creating a monitoring system ‘M' that is layered on top of a
> given system that one wishes to monitor, 'S'. ‘M' observes the execution of
> ’S’ via EVM tracing to try and detect infringements of certain logical
> properties specified over ’S’.
>
> The docs mention that suspend and resume are reserved for debugging
> purposes, and like you said in your reply, draws attention to the fact that
> careless use of these two functions can lead to inadvertent deadlocks. You
> mentioned also that automatic deadlock detection has been removed, hinting
> that that the implementation of suspend and resume might change in future
> releases of Erlang. I understand that. Besides this however, is there any
> other reason that suspend and resume should *not* be used? For instance,
> would executing suspend at any point, say, mess up the internal state of
> the suspended process?
>

Not unless there is a bug in the suspend functionality.


> This question is in light of what I said above, namely that I would
> suspend a process whilst it is executing without having knowledge of what
> instruction the suspendee is executing. ‘suspend_process/1’ blocks the
> suspender until suspendee is eventually suspended: does "eventually
> suspended" mean that it is safe to assume that the VM brings suspendee to a
> state where it is ok to suspend it?
>
>
Yes. The suspender sends the suspendee an asynchronous signal. The
suspendee wont suspend until it receives and handle the suspend signal.
Currently handling of such signals only occur when a process is scheduled
in, when executing a receive (depending on the state of the message queue),
and when scheduled out from a dirty scheduler. Signals are handled in
received order. If there are a lot of signals to handle, not all of them
are necessarily handled before continuing execution. That is, the suspendee
may pass one of these points where it handles incoming signals and then
continue execution even if there should be a suspend signal waiting for it.


> And out of sheer curiosity, is a suspendee suspended as soon as possible,
> or does the scheduler execute its remaining number of reductions before
> suspending it and returns control back to the suspender?
>
>
As described above, it suspends when it sees the suspend signal which might
or might not happen before the remaining number of reductions has been
exhausted.


> Once again, thanks a lot for your kind help Rickard.
>
> Best regards,
> Duncan.
>
>
>
>
Regards,
Rickard

-- 
Rickard Green, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191002/426f38bc/attachment.htm>