- User Since
- Mar 18 2020, 3:05 AM (65 w, 6 d)
Aug 30 2020
I've realized that I just didn't know about stop hooks... So, sorry and thanks, it solves almost all my problems except for notifying about "resume" events which are important for me too. But I can use synchronous Process::Notifications to receive them (I couldn't use Notifications to receive stop events because they are sent before the public state is changed by DoOnRemoval). But then I thought why don't we just move SynchronouslyNotifyStateChanged invocation from ShouldBroadcastEvent to DoOnRemoval? It would provide the most convenient way of receiving process events without intersections with the primary listener. I can make these changes in another patch instead of this one.
Aug 27 2020
Yeah, I understand the problem of two listeners trying to change process state simultaneously and I agree that informing other listeners once the primary one finished its job would be a great solution. But the problem is that primary listener just provides an event to some user code (via GetEvent) and there is no way to find out when this code has finished without requiring it to invoke a handshake explicitly.