> 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.
