Even if the fibers are small, they may invoke kernel calls which take a long time to complete (for example a large I/O operation). How do you ensure that other fibers can continue their work in such cases?
For example, to write a large file over the network, the scheduler write small piece of data at a time. And all socket are on non-blocking mode. So if the read/write operation would block, the OS just raise an "would block" error, and the scheduler use epoll to check back later.
To call synchronous function, there are solutions like forking the operation into on an other process. And there are different solutions for the process-communication : pipes, sockets, hlnet (our home made protocol used by our distributed DB), rest, soap...
Further, the smaller your fibers get, the more overhead you introduce for context-switching, right? Because I can imagine that after execution of each fiber you need to do some scheduling (even if the current fiber remains active). Is this context-switching faster than the kernel can do it?
Finally, I'm interested in what makes scheduling for the web such a specialized task, but that may be related to the previous question.
By "specialized", I mean it's better that fibers are scheduled by the application-scheduler itself, that knows the logic of the application and the purpose of each fibers, rather than the OS-scheduler. About context-switching, there is the small context-switching between fibers inside the main-thread, and the bigger context-switching between this mean thread and the others thread of the OS. So it really depends here on what we are trying to compare (and if it's comparable).