Re: [PHP-DEV] PHP socket ethernet support - step 2

Hi, > I am working on the second pass of this feature and write here because of > the legitimate concern regarding new classes to add. > > PR here > For those that want to quickly see the actually classes, here is a stub link: https://github.com/php/ph

[PHP-DEV] PHP socket ethernet support - step 2

Hi, I am working on the second pass of this feature and write here because of the legitimate concern regarding new classes to add. PR here I agree also on adding a namespace on top (Sockets ?) and changing the class names. Note that after that I plan

Re: [PHP-DEV] PHP True Async RFC

Hi, Nicolas. Hi Edmond, The target DX is that when outside any event loop, we're still able to leverage fibers to provide concurrency, for requests only, and when inside an event loop, requests run concurrently to any other things that the loop monitors. Is that something that could be a

Re: [PHP-DEV] PHP True Async RFC

> > Note the explicit use case I listed is that of an unlock() in a finally > block that *requires spawning a new fiber* in order to execute the actual > unlock() RPC call: this is explicitly in contrast with the RFC, which > specifies that > >*ATTENTION*: A programmer must *never* attempt to creat

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi,Am 03.03.2025 15:30 schrieb Volker Dusch :On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote:Volker and I would like to start discussion on our RFC to allow "Markingreturn values as important (#[\NoDiscard])".Please find the following resources for your reference:- RFC: http

Re: [PHP-DEV] PHP True Async RFC

Hi Edmond, Thanks for sharing the huge amount of work that went into this! I would really prefer it to be always enabled, no fallback at all, because > as I said, it will make absolutely no difference to legacy, non-async > projects that do not use fibers, but it will avoid a split ecosystem > sc

Re: [PHP-DEV] PHP True Async RFC

Lock/Unlock issue It seems that this is actually about a database query that puts the Fiber into a waiting state specifically, query("UNLOCK"). In that case, everything should work correctly. Although there are some dangerous edge cases. The database might be under high load, causing the q

Re: [PHP-DEV] PHP True Async RFC

I like context.WithCancel from Go, but it can essentially be implemented directly in PHP land since all the necessary tools are available. Note, this is precisely the problem, implement cancellation propagation to child fibers in userland PHP requires writing a bunch of boilerplate try-catch

[PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote: > Volker and I would like to start discussion on our RFC to allow "Marking > return values as important (#[\NoDiscard])". > > Please find the following resources for your reference: > > - RFC: https://wiki.php.net/rfc/marking_return_value_as_im

Re: [PHP-DEV] PHP True Async RFC

> On 3 Mar 2025, at 13:05, Edmond Dantes wrote: > >> As a heavy use of both amphp and go, cancellations (contexts in go) are >> absolutely needed, as a fiber may spawn further background fibers in order >> to execute some operation, just cancelling that specific fiber will not >> cancel the s

Re: [PHP-DEV] PHP True Async RFC

> > As a heavy use of both amphp and go, cancellations (contexts in go) are > absolutely needed, as a fiber may spawn further background fibers in order > to execute some operation, just cancelling that specific fiber will not > cancel the spawned fibers, unless a bunch of boilerplate try-catch blo

Re: [PHP-DEV] PHP True Async RFC

Hi, > Any Fiber can be canceled at any time, and there is no need to use explicit > Cancellation, which I personally find an inconvenient pattern. > As a heavy use of both amphp and go, cancellations (contexts in go) are absolutely needed, as a fiber may spawn further background fibers in order

Re: [PHP-DEV] PHP True Async RFC

> > There should be a defined ordering (or at least, some guarantees). The execution order, which is *part of the contract*, is as follows: 1. Microtasks are executed first. 2. Then I/O events and OS signals are processed. 3. Then timer events are executed. 4. Only after that are fibe