Re: [VOTE] True Async RFC 1.6

Op ma 24 nov 2025 om 15:03 schreef Rowan Tommins [IMSoP] < imsop.php@rwec.co.uk>: > - SDK Susie does not know what implementation of LoggerInterface will be > passed to her library. How does she know if it is safe to use in her > asynchronous code? As the LoggerInterface is injected into her SDK client and there is no distinction between an async and a sync Interface, Susie can't and doesn't really need to know this. She just uses the contract that is implied by the interface. > - Legacy Les is using a LoggerInterface implementation written years > ago. How does he know whether it is acceptable for use with Susie's library? As I see it, there's two kinds of "acceptable" in this case: blocking vs non-blocking and possible side effects. Blocking vs non-blocking: If Les does not care about blocking the event loop he can do whatever he wants. If he passes a Logger with a blocking I/O call (for example through some extension) the event loop would block for the duration of the I/O call. Acceptable in his case, as he does not seem to care about async. If Les wants to take advantage of non-blocking I/O he has to use a Logger which implements one of the non-blocking I/O functions (file_put_contents, ...). In this case I would expect the Scheduler to await that function call in the current coroutine. Is this correct Edmond? Possible side-effects: It is however possible that the expected output of the logs may have a different order than before Susie migrated her library from sync to async. Depending on how you look at it this might be a problem. I would expect Susie to release a new major version warning users of a possible break in backward compatibility. If Susie does not do that, Susie is at fault. If Susie does release a new major version I would expect Les to fix his dependency on shared state before upgrading to a new major version instead of blindly upgrading to a new version*. * which he shouldn't do anyways, async or not. Is this helpful? Best Regards, Bart Vanhoutte