ff_send data with large data with blocking-socket will fail

[renzibei]

I found that when I tried to use blocking socket with kqueue and sent a large data (e.g. 65536 bytes), the ff_send would simply fail because the sbwait in uipc_sockbuf.c:449 (which calls a fake sleep function _sleep in ff_kern_synch.c:91) returns 1.

As the developer responded in #30, I agree that it's not recommended to use blocking socket with kqueue. However, in real freebsd kernel, it is allowed to doing this. I think even if f-stack chooses to forbid this kind of usage, it should be noted in the documents. For example, how can the users know this will fail? And how large is the one-time sending length limit?

[MrSonicMaster]

blocking sockets do not make much sense in f-stack architecture, since it operates entirely single-threaded, with the kernel code being indifferent from the application code. blocking only makes sense if the task your sleeping on can actually be carried out concurrent with the sleeping.

[renzibei]

Thank you for reply. After these days of research I have basically figured this out more or less. That is to say, the programming mode of f-stack is fixedly driven by the event loop. What I'm still unclear about though is whether setting the socket to blocking mode or not makes any difference. Will the recv operation of a blocked socket cause sleep? According to my understanding f-stack uses the busy poll mode. So will it actually go to sleep state in recv? If it is said that sockets in non-blocking mode should be used everywhere, why is the socket not set to non-blocking mode in example/main.c?

Also like I said, I can understand such a design. But such limitations on functions and differences in behavior from standard POSIX operations should be documented. Otherwise the user cannot know the consequences in advance.

[MrSonicMaster]

I do agree, f-stack is not well documented, in many cases is unpolished, and perhaps is to be considered more of a DIY-type library for any features that tencent does not rely on themselves. I am, of course, still appreciative that their current progress has been made public. I am unsure why the example does not suggest to use non-blocking sockets, or in which cases a blocking socket will run into issues, but I presume tencent did little work/testing involving them and therefore it is unsafe to use them.

[jfb8856606]

Appropriate instructions will be added to the document for this part of the content, but it may not be very perfect.

[jfb8856606]

Added a simple description in ff_api.h and set non blocking in example/main.c in default, close this issue first.