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.

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.

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.

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

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