https://bugs.freedesktop.org/show_bug.cgi?id=63398
--- Comment #9 from Stephan Bergmann <[email protected]> --- (In reply to comment #8) > (In reply to comment #7) > > It is unclear to me > > though why the decision whether to call listeners directly or to postpone > > that via Application::PostUserEvent should be based on whether the listener > > method is marked as "oneway." > > To me, it makes sense. If the listener method says "I can be called > asynchronously" (that is, "I am a one-way method"), in particular it means > "there can be an arbitrary delay between the moment my caller asks for me > and the moment I actually execute; my caller is allowed to continue > executing *before* I start/finish executing." But that does not match the semantics of UNO "oneway" (where, rather, the emphasis is on the fact that the oneway method may run in parallel to the caller proceeding, not on a potential delay until the oneway method executes---the intent always was that the delay until the oneway method finishes is bounded by the next non-oneway method call made by the caller, even if the design was flawed; given the UNO "oneway" semantics, it would look more natural if FormScriptListener::firing would rather chose to not postpone listener invocation for the oneway listener case). To me, it looks like the heuristic of impl_allowAsynchronousCall_nothrow is just as bad as any other heuristic based on UNOIDL type information about the listener, but happened to work well for FormScriptListener::firing. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
