<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 2, 2019 at 8:41 AM Duncan Paul Attard <<a href="mailto:duncan.attard.01@um.edu.mt">duncan.attard.01@um.edu.mt</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>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.</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div>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.</div></div></blockquote></div><div><br></div><div>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. </div><div><br></div><div>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’.</div><div><br></div><div>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?</div></div></blockquote><div><br></div><div>Not unless there is a bug in the suspend functionality.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div> 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? </div><div><br></div></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div></div><div>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?</div><div><br></div></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div></div><div>Once again, thanks a lot for your kind help Rickard. </div><div><br></div><div>Best regards,</div><div>Duncan.</div><div><br></div><div><br></div><div><br></div></div></blockquote><div><br></div><div>Regards,<br></div><div>Rickard<br></div><br></div>-- <br><div dir="ltr" class="gmail_signature">Rickard Green, Erlang/OTP, Ericsson AB</div></div>