Multithreading

[notEvil]

Hi,

whats the stance regarding multithreading? It seems that sometimes callbacks are deliberately pushed to the message queue, like

PHONK/PHONK-android/phonk_apprunner/src/main/java/io/phonk/runner/apprunner/api/network/PBluetoothLEClient.java

Line 190 in 6afdc85

mHandler.post(() -> {

and other times not, like

PHONK/PHONK-android/phonk_apprunner/src/main/java/io/phonk/runner/apprunner/api/network/PHttpServer.java

Line 165 in 6afdc85

Response res = (Response) mCallback.event(ret);

or any sensor callback. From what I found, Rhino doesn't guarantee thread safety, so I guess the intended rule is to always push JS callbacks to the message queue, if necessary (sensors?).

If thats the case, I could scan the codebase for callbacks that potentially get called on a different thread, like the one in PHttpServer, and prepare a PR.

[victordiaz]

Hi @notEvil,
Most of the callbacks should run on the UI thread, just for simplicity sake when using some date from a callback in a UI element.

The HttpServer was not posting the data in the message queue because IIRC I had some issues with long data transfers. If you find a better way I will be happy to accept a PR to improve it :)

[notEvil]

I agree, one shouldn't be concerned about threads and PHttpServer seems to be an exception. This detail should be in the docs as it could potentially lead to race conditions. And because it is so easy to mix JS with Java code, maybe also have a separate document on this topic?

On a side note: just tested and confirmed my suspicion. Sensor callbacks are called by the main thread (using android.os.Process.myTid). Additionally, activities and services run on the same thread. This is probably common knowledge but it wasn't plain to me.

[victordiaz]

Yes, I agree. If you want you can add some documentation in the method itself or if you want you can add something to the Github wik as .md that I can include also in the websitei.

I will be happy to add more docs. I just never had the time. I think this is a great opportunity to improve it.

[notEvil]

The HttpServer was not posting the data in the message queue because IIRC I had some issues with long data transfers.

So you had the thread wait for the response at some point? Thats what I would do, and in case of large responses triggering the request timeout, it is still possible to do it asynchronously (e.g. respond nothing and do a request in the other direction).