johnpitcairn

I've identified a startup problem where if Java inits after a method is defer_lowed internally, but before that deferred method executes, the defer_low is no longer honoured and the method executes immediately.

I assume there is some sort of threading issue here. Has anyone encountered this before, and is there a workaround that will honour the defer_low?

Example Max 5 patch attached, with simple test object and its .c source (based on simplemax).

Note this behaviour is identical in Max 4.

bug-java-init-de-queues-defer_lowed-methods

I've found this is not 100% reproducible, depending on hardware. A multicore CPU seems to increase the likelihood of the behaviour - the attached object/patch is 100% reproducible on this 2.4GHz iMac, but not on a 1GHz G4 powerbook. A more complex version (using oo objects) is currently reproducible on the powerbook, but only in Max 4, not Max 5.

This certainly suggests a threading issue. Perhaps this is intended behaviour for defer_low?

Can we expect that object-instantiation is a single queue, and that a defer_low should reliably defer a method until after all objects instantiate at load?

Or may Java initialization alter the queueing model on multicore processors, so that the low-priority queue interrupts queued object instantiation? This is what I appear to be seeing.

Bug? Java init de-queues defer_lowed methods?