Logo
My Account |  Site Map | Contact Us  
Welcome Guest Search | Active Topics | Sign In | Register

JavaScript to C# bridge ordering of calls Options
JW
Posted: Friday, February 8, 2019 8:51:27 AM
Rank: Newbie
Groups: Member

Joined: 2/8/2019
Posts: 5
I've been reading the documentation for calling from JavaScript to C#.

To call C# from JavaScript I can register a function on the C# side:

Code: C#
...
webView.RegisterJSExtensionFunction("SomeCSharpMethod", new JSExtInvokeHandler(SomeCSharpMethod));
...

private void SomeCSharpMethod(object sender, EO.WebBrowser.JSExtInvokeArgs e)
{
  string message = e.Arguments[0] as string;
  ....


Then from the JavaScript I can call:

Code: JavaScript
SomeCSharpMethod("message1");
SomeCSharpMethod("message2");


A couple of things aren't clear to me from the documentation:

- are these two calls from the JavaScript to C# *always* handled in order (i.e. is there any scenario where the event handler in C# could see "message2" before "message1", or do the event handlers for the two calls race against each other, or are they run from the same C# thread (i.e. the first must finish before the second is dispatched?))?

- does JavaScript execution get blocked while the C# event handler is run?


Thanks,
Joe
eo_support
Posted: Friday, February 8, 2019 11:23:08 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 21,434
Hi,

You worried too much. :) JavaScript is single thread by design. So simple JavaScript function call ALWAYS blocks, this means on JavaScript side SomeCSharpMethod("message2") will not run until SomeCSharpMethod("message1") returns after your C# side handler for this call has already run and return.

Asynchronous/parallel programming for JavaScript does exist, but that's not the "default" mode. In another word, you have to do something special in order to break the sequential nature of the two calls.

Thanks!
JW
Posted: Friday, February 8, 2019 11:32:53 AM
Rank: Newbie
Groups: Member

Joined: 2/8/2019
Posts: 5
Sorry, I don't think I was clear enough.

I understand JavaScript is single threaded, my concern is the JavaScript to C# bridge.

When JavaScript calls to a C# function does this cause an event to be raised on the C# thread-pool, hence two calls made sequentially from JavaScript may actually result in two events which race against each other in C#?

Or does it go via some queue mechanism where one call (and it's associated event) is fully processed before the next is released?

Thanks.
eo_support
Posted: Friday, February 8, 2019 12:08:47 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 21,434
Hi,

My understanding is there are two separate questions that you brought up. I will try to answer one by one.

Order of message1 and message2

The C# bridge, or native C++ code in the browser engine that are used to implemented other "normal" JavaScript calls, are merely implication details of the JavaScript function you are calling. Regardless of the underlying implication details, due to the single thread nature of JavaScript, SomeCSharpMethod("message2") will not start until SomeCSharpMethod("message1") finishes. This means regardless what implementation mechanism is used to implement SomeCSharpMethod, the implementation code for "message2" will not be called until the implementation code for "message1" returns. This is the full sequence:

1. Enter SomeCSharpMethod("message1") JavaScript calls;
2. C# side handler is called for "message1";
3. SomeCSharpMethod("message1") JavaScript calls return;
4. Enter SomeCSharpMethod("message2") JavaScript calls;
5. C# side handler is called for "message2";
6. SomeCSharpMethod("message2") JavaScript calls return;

Regardless what happens inside step #2 and step #5, the overall sequence of the above steps will not change due to the single thread nature of JavaScript code. This is because the single thread nature of JavaScript code ensure each step won't happen until the previous step completes. For example, step 4 absolutely will not happen until step 3 completes no matter what you do in step 2. Likewise, step 3 absolutely will not happen before step 2 completes (what if step 2 needs to return a value?). So the above sequence is fixed.

Threading on C# side

Threading issue on the C# side is a valid point but it does not affect the sequence of execution in your original questions. Technically it is possible for us to run your handler code in thread pool thread. However if we were to do that then you may have to write synchronizing code to synchronize between your handler code (which now runs in a thread pool thread) and other code (assume they run in the main thread) --- for example, they may both need to access a data structure and allow the data structure to be accessed by two threads at the same time may corrupt it. This would be extra code on your end. As a result, currently we call the handler in your main thread (the same thread that created the WebView).

As already mentioned, in which thread your handler is called has no bearing in the sequence of things discussed in the previous section. Even if we were to choose to run the handler in a worker thread (or thread pool thread), we would still have to make sure that your handler code is done until we can notify the JavaScript side that this call is done. This means regardless in which thread the handler runs, step 2 will always occurs before step 3 and step 5 will always occurs before step 6.

Of course, if you decide to do other multi-threading stuff in your own handler, then that has nothing to do with JavaScript nor the C# bridge. For example, if you were to launch a background task every time your handler is called, then there would be no guarantee that tasks that are first launched finishes first. This is just general multi-thread programming that has nothing to do with anything discussed here.

Hope this is clear enough for you. Please let us know if you still have any questions.

Thanks!

JW
Posted: Friday, February 8, 2019 12:11:50 PM
Rank: Newbie
Groups: Member

Joined: 2/8/2019
Posts: 5
Perfectly clear, thanks for the quick and detailed response :)
eo_support
Posted: Friday, February 8, 2019 3:32:40 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 21,434
Great!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.