Files
Bubberstation/code/controllers/subsystem
fira bfb6ab224e Fix race condition in SSmapping z-level creation (#59560)
As described in issue #56733, there is a possibility of a race condition in SSmapping.add_new_zlevel - either during Z level incrementing, or the proc itself, as it only expands the amount of registered z-levels after being finished.

While the first hopefully shouldn't happen, it can still manifest because of the CHECK_TICK within. A practical result is that two concurrent calls to this proc will both create a new Z-level, but actually report having made the same first one.

This is problematic for map_templates that will then load blindly to the reported Z-level when using load_new_z, overwriting each other. We sometimes encounter that end result on CM13 codebase because of a map load that can be triggered by an user topic - if two people click at the same time, it's not unlikely for the first call to sleep in CHECK_TICK and let the second run, causing double-loading.
2021-06-09 14:01:29 -03:00
..
2021-02-16 18:20:16 -08:00
2021-03-21 06:02:26 -07:00
2021-05-08 04:29:14 -07:00
2021-06-04 21:46:56 -07:00
2021-03-28 12:10:18 -04:00
2021-03-07 22:13:32 -08:00
2021-03-28 12:10:18 -04:00
2021-03-17 05:51:53 -07:00
2021-03-28 12:10:18 -04:00
2021-05-27 19:50:36 +02:00