Consistency of `Task.current?` and `Task.current` about async HOT 10 CLOSED

Yes, I was referring to Task.current and Task.current?. I've updated my proposal.

from async.

Your points are completely valid; I though about them too, although, since the method Task.current! didn't exist yet, I though that it could be used to have those 3 meanings:

• Task.current!: give me the current Task or fail, since I must use it.
• Task.current: give me the current Task if there is one, so I could use it to run sub-tasks, instantiate a new Task, etc.
• Task.current?: is there a current task? / am I running inside a Task?

I mean, maybe some people could think that Task.current! would mutate the internal state, as Array#sort! does, but in this context is referring to a class, not an instance, which is a signal to think more about it, and, maybe I'm wrong with this affirmation, but Task.currrent/Task.current! couldn't be run in a task outside the current task of the thread.

In any case, I'm aware of that it could be hard to apply this proposal (maybe until 2.0.0?).

from async.

OK.

About using Task.current without raising an error, I was thinking on something like:

task = Task.current or Task.new
# This (^) is less confusing IMO than:
# task = Task.current? or Task.new
subtask = task.async do |subtask|
  ...
  run_blocking_op
  ...
end
...
run_nonblocking_op

Does this use case make sense?

from async.

Sorry, I was thinking about a way to use Task.current without raising an error, not a real-world example, and I didn't realize that it was quite an awful example.

To be clearer, I was thinking about something as verbose as this:

def run(task = nil)
  task ||= Task.current or Task.new
  # This (^) is less confusing IMO than:
  # task ||= Task.current? or Task.new
  subtask = task.async do |subtask|
    ...
    run_blocking_op
    ...
  end
  ...
  run_nonblocking_op
end

# Create a task (and a reactor) and run until a blocking operation, then asynchronously
run

# Run asynchronously using the passed task
Async do |task|
  run task
end

# Run asynchronously using the container (threads or processes)
container = Async::Container.new
run container

But it's completely unnecessary:

def run
  subtask = Async do |subtask|
    ...
    run_blocking_op
    ...
  end
  ...
  run_nonblocking_op
end

# Create a task (and a reactor) and run until a blocking operation, then asynchronously
run

# Run asynchronously using the current task
Async do
  run
end

# Run asynchronously using the container (threads or processes)
container = Async::Container.new
container.async do
  run
end

from async.

Task#current? does return a boolean in all cases:

		def current?
			self.equal?(Thread.current[:async_task])
		end

Task.current is guaranteed to never be nil, or be an error. It should be used in situations where you expect to be running in a task. Task.current? means optionally return nil.

		# Lookup the {Task} for the current fiber. Raise `RuntimeError` if none is available.
		# @return [Async::Task]
		# @raise [RuntimeError] if task was not {set!} for the current fiber.
		def self.current
			Thread.current[:async_task] or raise RuntimeError, "No async task available!"
		end
		
		# Check if there is a task defined for the current fiber.
		# @return [Async::Task, nil]
		def self.current?
			Thread.current[:async_task]
		end

There is no such thing as Task#current and Task#current?. Maybe you mean Task.current and Task.current?. The point of the naming convention is to help people use the correct one Task.current. If you are using Task.current? a lot, there may be something wrong with your code.

from async.

So, even if I agree with your assessment (and objectively it's an equally reasonable proposal, but it optimises for different conventions), this is already a public interface which is in use by lots of other gems. So, practically speaking, it's probably impossible to change.

The key point to understand is:

• Task.current should never be nil in the contexts in which it's called. The fact it raises an exception is not something you should be concerned with. In all contexts that it is called correctly, it should not be nil.

• If one was to implement Task.current!, one might expect as per convention this mutates some internal state, e.g. setting the task as the current one... so maybe equally confusing as my usage of Task.current?.

• If, for some reason, you aren't sure, you should use Task.current?, which means, maybe there is a current task, not "is ther a current task?".

• Task#current? asks "Is the specified task the current one?".

from async.

Agree with all your points. Not sure it would even be possible with 2.0.0 as it would break backwards compatibility and you'd have to weight that in terms of what you gain by changing the interface.

Agreed, Task.current! would make total sense, except for one point: the default behaviour that I want is actually Task.current. Users should not use Task.current? or Task#current? except in very specific situations. So if I would do anything, I could make Task.current! an alias of Task.current and leave Task.current? alone. But for me, that Task.current? means "the current task, maybe?", so I'm okay with that.

Then, for Task.current!, yes, I feel it's more conventional, but there is no point for Task.current to exist if Task.current! exists. You should not be capturing the exception thrown by Task.current, it's actually a semantic error of your program if that happens. So, encoding that into the method name doesn't make as much sense to me.

from async.

Without being condescending, no, it doesn't make a huge amount of sense.

There are two entry points you should use.

Async do
end

Sync do
end

You should almost never need to use Task.current except in very specific situations. So your code should simply be:

subtask = Async do |subtask|
  ...
  run_blocking_op
  ...
end
...
run_nonblocking_op

Just let async take care of the semantics, and you worry about expressing your non-determinism.

from async.

If you are running in a nested context and are a few layers deep, a valid pattern is:

def run(parent: Async::Task.current)
  parent.async do
  end
end

This method will not run outside of an async block.

from async.

OK, thanks for the tip.

from async.