You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Could init(Weave) take in an optional procedure that gets executed on every thread (i.e. no stealing, inside of worker_entry_fn) on startup before their respective event loops start?
Sometimes there is a need for preconfigured thread-local initial state that we have to have applied to all threads - spawning a proc after init is potentially error-prone due to the work-stealing mechanism. The specific use case I am thinking of involves the FPU state. In games and other realtime applications, handling denormal IEEE 754 values can cause increased arithmetic latency so we setup the FPU on program initialization to compress denormal values to zero (DTZ) wherever possible. Because each thread has its own FPU state, DTZ needs be activated on all threads we're handling arithmetic on. There may be other use cases for a user-specifiable per-thread startup procedure but this is the most significant one I can think of.
The text was updated successfully, but these errors were encountered:
Could
init(Weave)
take in an optional procedure that gets executed on every thread (i.e. no stealing, inside ofworker_entry_fn
) on startup before their respective event loops start?Sometimes there is a need for preconfigured thread-local initial state that we have to have applied to all threads - spawning a proc after init is potentially error-prone due to the work-stealing mechanism. The specific use case I am thinking of involves the FPU state. In games and other realtime applications, handling denormal IEEE 754 values can cause increased arithmetic latency so we setup the FPU on program initialization to compress denormal values to zero (DTZ) wherever possible. Because each thread has its own FPU state, DTZ needs be activated on all threads we're handling arithmetic on. There may be other use cases for a user-specifiable per-thread startup procedure but this is the most significant one I can think of.
The text was updated successfully, but these errors were encountered: