34 ms·

I think this is a hoax/joke? The performance test is bizarre, and literally nothing in the development guide ever shows anything but single-thread serial code

I think this is a hoax/joke? The performance test is bizarre, and literally nothing in the development guide ever shows anything but single-thread serial code for i/o. What, exactly, happens if a second user accesses the website while a request is processing? Also the docs don't explain how fibers are being used -- what is the scheduling strategy? Is there even more than one fiber?

strangattractor 4y ago
You have to couple it to ImodiumJS which allows calling fibers asynchronously.
- mhio 4y ago
  Damnit.. I even searched for it =)
rizky05 4y ago
[dead]
olegp 4y ago
It's not a joke. There is no scheduling strategy, since fibers allow only for non pre-emptive multitasking. There may be multiple fibers, but only one running at a time within the same process. If a second request comes in while another is processing and assuming that the first doesn't yield control by doing I/O, for example, then the second request isn't processed until the first one completes. If the first does yield control, then the two may be processed in parallel within the same process, just like with async/await.
- tommiegannert 4y ago
  There can be several fibers ready to run, e.g. if a mutex or condition variable is being waited on by multiple fibers. You still have to choose which one to run next. If you choose wisely, you might, e.g. be able to free up memory from closures that go out of scope quicker than others. Think of a data-shuffling pipeline that also updates statistics (in the background): running the next stage of the pipeline is more likely to get rid of lots of memory chunks than is running the statistics code. It also improves pipeline latency, of course. The scheduling definitely matters even for cooperative threading.
  - olegp 4y ago
    You're right and I was wrong to say that a scheduler isn't needed. I assume a fiber scheduler is usually much simpler than a thread scheduler though, since it just needs to decide which fiber to run, rather than how long to run a thread for and where.

strangattractor 4y ago

You have to couple it to ImodiumJS which allows calling fibers asynchronously.

mhio 4y ago
Damnit.. I even searched for it =)

rizky05 4y ago

[dead]

olegp 4y ago

It's not a joke. There is no scheduling strategy, since fibers allow only for non pre-emptive multitasking. There may be multiple fibers, but only one running at a time within the same process. If a second request comes in while another is processing and assuming that the first doesn't yield control by doing I/O, for example, then the second request isn't processed until the first one completes. If the first does yield control, then the two may be processed in parallel within the same process, just like with async/await.

tommiegannert 4y ago
There can be several fibers ready to run, e.g. if a mutex or condition variable is being waited on by multiple fibers. You still have to choose which one to run next. If you choose wisely, you might, e.g. be able to free up memory from closures that go out of scope quicker than others. Think of a data-shuffling pipeline that also updates statistics (in the background): running the next stage of the pipeline is more likely to get rid of lots of memory chunks than is running the statistics code. It also improves pipeline latency, of course. The scheduling definitely matters even for cooperative threading.
- olegp 4y ago
  You're right and I was wrong to say that a scheduler isn't needed. I assume a fiber scheduler is usually much simpler than a thread scheduler though, since it just needs to decide which fiber to run, rather than how long to run a thread for and where.