Inconsistency between @async warning and its usage in documentation

General Usage
,
1

Recently I was answering an @async related question, and I remembered a documentation warning against @async usage. After checking that out, it was still there:

It is strongly encouraged to favor Threads.@spawn over @async always even when no parallelism is required especially in publicly distributed libraries. This is because a use of @async disables the migration of the parent task across worker threads in the current implementation of Julia. Thus, seemingly innocent use of @async in a library function can have a large impact on the performance of very different parts of user applications.

However, when looking, for example, at the Channels we see @async is being used when instructing how people should use Channels.

So, either the warning is outdated, or the usage of @async in other places of the documentation is somehow problematic (I don’t think it is fair to have people go and check if using @async is good practice - since it is already used in the documentation as a proper way to do things - in this case Channels).

So, which one should we change?

3 Likes
2

I’m not sure how related this is but I also came across the following in the docs

Instead of errormonitor(t), a more robust solution may be use use bind(results, t), as that will not only log any unexpected failures, but also force the associated resources to close and propagate the exception everywhere.

As with @async, the example in the section uses errormonitor(@async dowork()) whereas I guess the approach being recommended would actually be bind(channel, @spawn dowork()) ?

1 Like
3

I also opened an issue here.

It seems it is known that the manual is outdated.

1 Like