Valery Silaev

Juan, Is data consistent after regular `TaskSchedle.execute()`? If "yes", then how it can be inconsistent after asynchronous completion of the latest event in OpenCL pipeline (or commands queue) or PTX...

Juan, I see your point. But once developers get to work with async pipelines created from `CompletableFuture` they never trap into such issues ) What concerns me more is the...

... or alternatively we might have 2 overloaded versions: the one with implicit executor, and the one with `ForkJoinCommonPool` passed explicitly. Sure, developers still have good chances to shoot themselves...

> I am not sure I completely follow. > > > we have to attach gpu thread from JNI and invoke Java code. When doing callbacks from JNI code to...

I'm trying to implement some proto. What I'm observing in ```java @Override public void waitOn() { if (VM_USE_DEPS && event != null) { event.waitOn(); } else { executionContext.getDevices().forEach(TornadoDevice::sync); } }...

> TornadoVM uses a single OpenCL command queue at the moment. ??? I.e. one queue shared by all `TaskSchedule`? Then it makes no sense to introduce any asynchronous capabilities while...

The `CLEventsWrapper` already holds all events fired to command queue. So adding callbacks to them and coordinating them should do the `async` trick. Any reason why Device -> Host is...

> Only the last transfer is blocking. No, there is no specific reason. We plan to remove the sync after the execute for blocking calls. Could you point me where...

For testing I've done 2 changes: 1. Altered `uk.ac.manchester.tornado.runtime.TornadoVM` to use non-blocking read in `executeStreamOutBlocking` (btw, `executeStreamOut` here uses blocking call on `TornadoContextDevice` - it looks like an error). 2....

> There are two main points: At the task-schedule level and the TornadoVM level Yep, found it. There are were many other issues that I had to fix when trying...