Re: [VOTE] True Async RFC 1.6

> An error will occur for whom? SDK Susie when unit testing her library? If SDK Susie used a new coroutine in which she calls the LoggerInterface::flush() method, then with some probability the user may notice that log entries are sometimes duplicated because the LoggerInterface::logs property is not being cleared. You could say that SDK Susie is responsible for this, because she ran code that was never intended to be executed in a concurrent environment. > If it is an error for SDK Susie, what is her solution to allow users to pass in a logger to her > library? To avoid the error, SDK Susie must be sure that the **LoggerInterface** implementation supports concurrent execution. If SDK Susie knows that LoggerInterface does not support asynchronous code, then she should not attempt to call its methods in a separate coroutine and should use LoggerInterface in the usual synchronous way. The shared-nothing memory model doesn’t even give SDK Susie a chance to make this mistake, because it simply forbids the existence of an object with two references. > If it is an error for Legacy Les, how does he fix it? In this case, we should assume that the responsibility for correctness lies with the one who provides the new functionality. Therefore, Legacy Les should not have to do anything. However, if Legacy Les wants to use the library, he needs to do the following: ```php function flush(): void { $data = $this->logs; $this->logs = []; // It is guaranteed to execute without interruptions. file_put_contents(implode("\n", $data), FILE_APPEND); } ``` I want to point out right away that the code above is not suitable for multithreaded execution.