I am looking for a list of things that are not safe to do inside a Threads.@threads loop. I am aware that this is as high-level as it gets, and I am sorry about that.
For example, I realized myself that I cannot println from a thread (differently to doing println from an addprocs-ed worker process) before I found this issue on DiffEq. I’d love to have a list of things that don’t work - maybe here, maybe in the manual, maybe as an issue? Thanks.
One high level heuristic is that anything that does IO will not work, ie any disk reads/writes, network reads/writes or console reads/writes. Also, the GC is not threadsafe yet, so you should not allocate inside a @threads loop.
I think I’ve read the same somewhere - but are you sure this applies to allocations? I’d have thought that this just means you can’t invoke the gc explicitely
Regexes are not thread-safe (StrRegex.jl is though! ) BigFloats are not completely thread-safe (because of global state for the precision and rounding mode)
(printing any floating point (Float16, Float32, Float64, BigFloat, Dec32, Dec64, Dec128, etc.) or converting it to a string used to be not thread-safe, but I believe that’s fixed now (converting or printing to an IOBuffer at least) BigInts also used to have the problems with converting to string and printing, but I also think that’s fixed as well.
Those are the ones that I’ve run into in Base.
I’m sure there are a lot more in packages, any time there are some settable values (like the default precision or rounding mode) that are stored in global variables, they will not be thread-safe.