social.noyu.me

my modest proposal is that such systems should check if appropriate event handlers are registered before you do something that can produce an event, and if they aren’t, refuse to deliver the event later, even if handlers were set up in the meantime 😈

@hikari just give the receiver control if buffering is plausible/reasonable https://developer.mozilla.org/en-US/docs/Web/API/MessagePort/start

@hikari@social.noyu.me it'll just execute whenever it feels like it

@hikari this is a very Hyrum's Law kind of problem :/

@hikari …in the same runloop iteration, or a subsequent one?

@saagar same runloop iteration… usually. ah, are you going to tell me there’s some guarantee about this? :)

@saagar something I’m not sure about is how NSNotificationCenter interacts with run loops.

@hikari I haven’t looked at this closely but I think the default is enqueuing but IIRC NSNotificationQueue lets you bypass that

@saagar ahh okay. touchHLE currently has an ad-hoc notification queue inside the “movie player”, simply because it never worked when I posted the notification immediately, but maybe I actually should put that queueing inside NSNotificationCenter itself…

@hikari @saagar NSNotificationCenter delivers notifications immediately, on the thread they’re sent on. (NSDistributedNotificationCenter is obviously different.)

@al45tair @hikari ^ you should generally trust the Cocoa veterans rather than me on this

@hikari I would definitely not write code relying on this but I would expect events to be queued for dispatch on the next iteration of the runloop