Hi, > > > I thought about this quite a bit and I think we should first try to > clarify the primary design that we want to go for. > > What I mean is whether we would like to ever support a true concurrency > (threads) in it. > > If we think it would be worth it (even thought it wouldn't be initially > supported), then we should take it into the account from the beginning and > add restrictions to prevent race conditions. > > > > If you mean multitasking, i.e., executing coroutines in different OS > threads, then this feature is far beyond the scope of this RFC and would > require significant changes to the PHP core (Memory manager first). >
You might want to look to parallel extension as it's already dealing with that and mostly works - of course combination with coroutines will certainly complicate it but the point is that memory is not shared. > And even if we imagine that such changes are made, eliminating data races > without breaking the language is, to put it mildly, a questionable task > from the current perspective. > That's exactly what I meant is to make sure that there won't be any data races - it means use only channel communication (more below). > > Although this RFC raises the question of whether a concurrent version > without multitasking is worth implementing at all, my opinion is positive. > For PHP, this could be sufficient as a language primarily used in the > context of asynchronous I/O, whereas a multitasking version may never > happen. > > I didn't really mean to introduce it as part of this RFC. What I meant is to design the API so there is still possibility to add it in the future without risking various race condition in the code. It means primarily to put certain restrictions that will prevent it like limited access to global and passing anything by reference (including objects) to the running tasks. Regards Jakub
