The lexical state abstraction in this library leaks in one big way: if you fork a thread (e.g. with async), the lexical state isn't preserved. This is because the current ThreadID is used to retrieve data. This is the magic that makes the state modification lexical: I create a new thread for the scope, copy the vault at this ThreadId, then we have a piece of state only accessible until this scope end.
But if you spawn a new thread with async in this scope, then it won't be copying the vault. The connection with the parent scope is lost. I don't think that it's the expected behaviour (though, technically, threads escape their scopes). One way is to provide wrapper for forkIO, async, etc… which save the state. There's a thread-local state library which does that but I can't find it at the moment.
Anyway, that's the situation right now.
The lexical state abstraction in this library leaks in one big way: if you fork a thread (e.g. with
async), the lexical state isn't preserved. This is because the currentThreadIDis used to retrieve data. This is the magic that makes the state modification lexical: I create a new thread for the scope, copy the vault at thisThreadId, then we have a piece of state only accessible until this scope end.But if you spawn a new thread with
asyncin this scope, then it won't be copying the vault. The connection with the parent scope is lost. I don't think that it's the expected behaviour (though, technically, threads escape their scopes). One way is to provide wrapper forforkIO,async, etc… which save the state. There's a thread-local state library which does that but I can't find it at the moment.Anyway, that's the situation right now.