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
It appears that pmap-core zips the ordered tasks with an unordered queue of derefable results of those tasks, and sometimes the second value (returned by a blocking take from the unordered queue) returns nil, causing deref-fixing-exceptions to deref that nil value, throwing the above exception.
So, something in the implementation of the blocking take from the unordered queue is causing it to return nil. I can only guess this is a race condition because it seemed to happen randomly. Anecdotally, I saw it happening more in 1.1.4 than in 1.2.2.
I don’t have steps to reproduce, but we fixed the issue in our system by just switching from upmap to pmap, which avoids what I think is the problematic zip operation above.
The text was updated successfully, but these errors were encountered:
Using
upmap
sometimes results in this exception:It appears that
pmap-core
zips the ordered tasks with an unordered queue of derefable results of those tasks, and sometimes the second value (returned by a blocking take from the unordered queue) returns nil, causingderef-fixing-exceptions
to deref that nil value, throwing the above exception.So, something in the implementation of the blocking take from the unordered queue is causing it to return nil. I can only guess this is a race condition because it seemed to happen randomly. Anecdotally, I saw it happening more in 1.1.4 than in 1.2.2.
I don’t have steps to reproduce, but we fixed the issue in our system by just switching from
upmap
topmap
, which avoids what I think is the problematic zip operation above.The text was updated successfully, but these errors were encountered: