It should be fine - as far as I know, spawned tasks run in the world age they’re spawned in, so using on the main thread shouldn’t interfere with already running code as that increases the world age.
See this for a negative example (trying to access something that is only available in the future from the POV of the spawned task):
julia> f() = begin sleep(10); g() end
julia> t = Threads.@spawn f()
Task (runnable) @0x00007f6de219ce70
julia> g() = "hello"
g (generic function with 1 method)
julia> fetch(t)
ERROR: TaskFailedException
Stacktrace:
[1] wait
@ ./task.jl:322 [inlined]
[2] fetch(t::Task)
@ Base ./task.jl:337
[3] top-level scope
@ REPL[9]:1
nested task error: MethodError: no method matching g()
The applicable method may be too new: running in world age 31218, while current world is 31219.
Closest candidates are:
g() at REPL[8]:1 (method too new to be called from this world context.)
Stacktrace:
[1] f()
@ Main ./REPL[4]:1
[2] (::var"#1#2")()
@ Main ./threadingconstructs.jl:178
Without defining g(), you get a regular MethodError from the spawned task, since there isn’t even one in the future. “World age” is one of the reasons why julia can be dynamic with eval and still be compiled instead of interpreted.