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
Hi!
Good job, and there is a lot of wit in it. The two-thread solution is great.
But I found two types of events, that should be processed in recv-thread, not in an event one.
Inspector.targetCrashed -- tab crash. Problem is: after this event there will be no answers for waiting calls (not even with errors -- nothing! on chromium 66.0.3359.181 at least), so if you just put it in the event queue, you may not get it after all. Your still working event handlers may hang up, waiting for an answer. So after Inspector.targetCrashed have arrived, you should call stop() immediately in the _recv_loop function.
Calling methods in not-main targets (chrome terminology for threads). You call it through method Target.sendMessageToTarget and get an answer through event Target.receivedMessageFromTarget. The problem is: if you are in an event-handler and you operate in one thread, you can not just wait for an answer -- it will never come. It will come in recv, and will be enqueued, but would not be processed until your current handler is finished -- it is a deadlock.
There is a workaround of cause. You can start a separate thread for every event handler, that call any API methods. But it is an ugly solution.
I actually use it now, and it seems to work ok.
Maybe you can adapt this idea and use it in your library?
P.S. For clarity. The "idea" here is just some possibility to install recv-time handlers for messages. All other just implementation details and example.
The text was updated successfully, but these errors were encountered:
Hi!
Good job, and there is a lot of wit in it. The two-thread solution is great.
But I found two types of events, that should be processed in recv-thread, not in an event one.
Inspector.targetCrashed -- tab crash. Problem is: after this event there will be no answers for waiting calls (not even with errors -- nothing! on chromium 66.0.3359.181 at least), so if you just put it in the event queue, you may not get it after all. Your still working event handlers may hang up, waiting for an answer. So after Inspector.targetCrashed have arrived, you should call stop() immediately in the _recv_loop function.
Calling methods in not-main targets (chrome terminology for threads). You call it through method Target.sendMessageToTarget and get an answer through event Target.receivedMessageFromTarget. The problem is: if you are in an event-handler and you operate in one thread, you can not just wait for an answer -- it will never come. It will come in recv, and will be enqueued, but would not be processed until your current handler is finished -- it is a deadlock.
There is a workaround of cause. You can start a separate thread for every event handler, that call any API methods. But it is an ugly solution.
I suggest something like that:
crashed_tab.txt
I actually use it now, and it seems to work ok.
Maybe you can adapt this idea and use it in your library?
P.S. For clarity. The "idea" here is just some possibility to install recv-time handlers for messages. All other just implementation details and example.
The text was updated successfully, but these errors were encountered: