Good day, Alex.
>
> Can you please share a bit more details on how the Scheduler is
implemented, to make sure that I understand why this contradiction exists?
Also with some examples, if possible.
>
```php
$fiber1 = new Fiber(function () {
echo "Fiber 1 starts\n";
$fiber2 = new Fiber(fu
>
> Maybe, we could create a different version of fibers ("managed fibers",
maybe?) distinct from the current implementation, with the idea to
deprecate them in PHP 10?
> Then, at least, the scheduler could always be running. If you are using
existing code that
> uses fibers, you can't use the new
On Sun, Mar 9, 2025, 09:05 Edmond Dantes wrote:
> When a *Fiber* from the *Scheduler* decides to create another *Fiber* and
> then tries to call blocking functions inside it, control can no longer
> return to the *Scheduler* from those functions.
>
> Of course, it would be possible to track the s
On Sun, Mar 9, 2025, at 09:05, Edmond Dantes wrote:
> Good day, Alex.
>
> >
> > Can you please share a bit more details on how the Scheduler is
> > implemented, to make sure that I understand why this contradiction exists?
> > Also with some examples, if possible.
> >
>
> ```php
> $fiber1 = ne
>
> The wait_all block is EXPLICITLY DESIGNED to meddle with the internals of
async libraries,
>
How exactly does it interfere with the implementation of asynchronous
libraries?
Especially considering that these libraries operate at the User-land level?
It’s a contract. No more. No less.
>
> Lib
On 08/03/2025 22:28, Daniil Gentili wrote:
Even its use is optional, its presence in the language could lead
library developers to reduce concurrency in order to allow calls from
async blocks, (i.e. don't spawn any background fiber in a method call
because it might be called from an async {} bl
>
> I think the same thing applies to scheduling coroutines: we want the
Scheduler to take over the "null fiber",
>
Yes, you have quite accurately described a possible implementation.
When a programmer loads the initial index.php, its code is already running
inside a coroutine.
We can call it the
>
> I can give you several examples where such logic is used in Amphp
libraries, and it will break if they are invoked within an async block.
>
Got it, it looks like I misunderstood the post due to my focus. So,
essentially, you're talking not so much about wait_all itself, but rather
about the p
On 08/03/2025 20:22, Edmond Dantes wrote:
For coroutines to work, a Scheduler must be started. There can be only
one Scheduler per OS thread. That means creating a new async task does
not create a new Scheduler.
Apparently, async {} in the examples above is the entry point for the
Scheduler
2025年3月8日(土) 19:06 Niels Dossche :
>
> On 08/03/2025 03:30, youkidearitai wrote:
> > Hi, Internals
> >
> > The add mb_levenshtein was end and declined.
> > Vote result is one yes and 5 no.
> >
> > Thank you very much voting.
> >
> > By the way, This message is means add grapheme_levenshtein instea
> I think you've misunderstood what I meant by optional. I meant that putting
> the fiber into the managed context would be optional *at the point where the
> fiber was spawned*.
>
> It sounds like you think:
>
> 1) The language absolutely needs a "spawn detached" operation, i.e. a way of
> st
>
> Have a different method `Fiber::suspendToScheduler(Resume $resume)` that
would return the control to the Scheduler.
>
That's exactly how it works. The RFC includes the method Async\wait()
(Fiber::await() is nice), which hands control over to the Scheduler.
At the PHP core level, there is an eq
>> The wait_all block is EXPLICITLY DESIGNED to meddle with the internals of
>>async libraries,
>>
>
> How exactly does it interfere with the implementation of asynchronous
> libraries?
> Especially considering that these libraries operate at the User-land level?
> It’s a contract. No more. No
Edmond,
The language barrier is bigger (because of me, I cannot properly explain
it) so I will keep it simple. Having "await" makes it sync, not async. In
hardware we use interrupts but we have to do it grandma style... The main
loop checks from variables set on the interrupts which is async. So yo
> Edmond,
>
> If you want to make async PHP with multiple processes you have to check
> variables semaphored to make it work.
>
>
Hello, Iliya.
Thank you for your feedback. I'm not sure if I fully understood the entire
context. But.
At the moment, I have no intention of adding multitasking
On Sun, Mar 9, 2025, at 14:17, Rowan Tommins [IMSoP] wrote:
> On 08/03/2025 20:22, Edmond Dantes wrote:
> >
> > For coroutines to work, a Scheduler must be started. There can be only
> > one Scheduler per OS thread. That means creating a new async task does
> > not create a new Scheduler.
> >
> >
On Sun, Mar 9, 2025, at 8:17 AM, Rowan Tommins [IMSoP] wrote:
> That leaves the question of whether it would ever make sense to nest
> those blocks (indirectly, e.g. something() itself contains an async{}
> block, or calls something else which does).
>
> I guess in our analogy, nested blocks cou
On Sun, Mar 9, 2025, at 11:56 AM, Edmond Dantes wrote:
> *Let me summarize the current state for today:*
>
> 1. I am abandoning `startScheduler` and the idea of preserving
> backward compatibility with `await_all` or anything else in that
> category. The scheduler will be initialized implicitly
On Thu, Mar 6, 2025, at 09:04, Tim Düsterhus wrote:
> Hi
>
> Am 2025-03-06 07:23, schrieb Rob Landers:
> > So, technically, they aren’t required to be in the same RFC; but also,
> > they complement each other very well.
>
> They really should be separate RFCs then. Your RFC text acknowledges
>
19 matches
Mail list logo
