ST3: async callbacks are not async

[schlamar]

The new async callbacks use dummy threads internally so there are not really async (at least on my Windows 64bit Version, Build 3012).

Example plugin: https://gist.github.com/schlamar/4986014 (have a look at the timestamps!)

[bizoo]

Depends of the meanings of async,

Try to use set_timeout() in place of set_timeout_async() and you'll see the difference:
ST3 freeze completely during the sleep() execution.

[schlamar]

It might be acceptable if one plugin only blocks itself but if one plugin could block ALL others plugins this violates the term "async".

I don't understand why he is using dummy threading instead of threading, because with the latter everything should be fine and working as expected.

[bizoo]

Yes you're right, it doesn't look optimal.
Only Jon could answer...

[castles_made_of_sand]

I guess the current way just leaves you to manage your own thread life cycles, probably for the better.

Even using the *_async apis you generally don't wanna do too much work without spawning your own thread.

[jps]

The new async callbacks use dummy threads internally so there are not really async

Your conclusion is incorrect. Dummy threads in Python simply refer to threads not created by Python. The async callbacks are indeed run from a separate thread, but the thread is not created by Python code.

That being said, all async calls are currently run in a single worker thread. There's nothing to stop plugins from creating their own threads, however.

[schlamar]

Sorry, I don't want to be rude, but IMO the new async API is just a half-baked concept which doesn't solve anything.

Maybe you should developers encourage to use the new "futures" concept which is exactly intended for such async operations and much more powerful:
http://docs.python.org/3/library/concur ... tures.html. It even can be backported to ST2: https://pypi.python.org/pypi/futures.

Here is a small example as proof of concept: https://gist.github.com/schlamar/4994029

[castles_made_of_sand]

@schlamar

Try and understand before losing your shit

Btw, how would you imagine that `add_future_callback` queues a callback on the main thread? It won't magically happen.

The callback will be run in the executor thread. It's senseless to submit highlight_view to the executor. You should be doing what you are instead for ST2.

For ST2 you have to use `sublime.set_timeout` to call back into the main thread

[jps]

schlamar: There are plenty of places on the internet to be uncivil, but this forum is not one of them. If you feel the need to prefix something with "I don't mean to be rude" or similar, then just don't say it at all.

If a plugin wants to use futures, a plugin can use futures. S3 is fundamentally the same as S2 here, it relies on plugin authors putting in the (large) effort to ensure their plugin doesn't do any significant work on the main thread. The async events provide one way to do this, and the threadsafe API is another way that S3 makes things simpler for plugin authors. Neither has to be used, they're simply options that people have. Both of these could be done in S2, via threads and set_timeout, respectively, but the S3 approach makes things a little easier for plugin authors. Saying 'use futures', in and of itself, would not.

[schlamar]

@castles_made_of_sand
Thanks for the update. The other async library I'm currently working with is queuing automatically callbacks on the main thread so I missed this. But as you already have pointed out, a fix is really straightforward.