blocking check in test will fail in future virtual thread-backed core.async

[puredanger]

The test in nodely.engine.core-async.lazy-scheduling-test:

(deftest blocking-tagging-test
  (testing "about the blocking tag"
    (testing "go-checking system property is set"
      (is (Boolean/getBoolean "clojure.core.async.go-checking")))
    (testing "eval of an env with blocking ops in dispatch worker pool provokes exceptions, evaling same ops in threads doesn't"
      (is (match? [true java.lang.IllegalStateException]
                  (update (nasync/eval-key env-with-blocking-take :d)
                          1
                          class))))))

will eventually no longer work once we move to virtual threads in core.async. When we get to that point (there is no release of this yet, but it's coming), go-checking is probably not going to actually work anymore, because there will be no way to detect that a blocking op is actually in the context of a go block (and actually, this code will now work on vthreads).

I'm not sure if that means the test should be removed or further qualified to understand the conditions where it is valid.

[aredington]

In nodely one of our problems is that we need to allow clients to express when work must not be dispatched to the dispatch worker thread pool, for work that will be blocking io. We created a semantic of tagging nodes of nodely graphs as blocking, and, when nodes are so tagged, scheduling the evaluation of those nodes to the thread pool instead of the go pool.

In JVMs <21, this will always be a concern when using core.async.

In JVM 21+, we already have semantics around checking for support for virtual threads in nodely. If we have similar features that we can detect for in core.async, then we can appropriately decide if this test is relevant when running on JVM 21+ and with core.async version-Virtual-Thread-Go-Blocks+

[jtrunick]

@aredington My takeaway from this is that with virtual threads there is no advantage to marking a node as blocking. Is that correct?