search

h2o / h2o

H2O - the optimized HTTP/1, HTTP/2, HTTP/3 server
https://h2o.examp1e.net
MIT License
10.86k stars 839 forks source link

accept4 not allways inplemented on systems #524

Open diecyde opened 9 years ago

diecyde commented 9 years ago

I found that accept4 is not always implemented in all libraries and kernels. In some implementations this function is stubbed and will return -1 always. Thus rendering the webserver unreachable. Uncommenting the linux define is not directly an option. So I ifdeffed an normal accept into the code.

Before I commit this patch, I would like to ask if maybe we could just replace accept4 with accept and fcntl ? Or is there a good reason to stick with accept4?

kazuho commented 9 years ago

@diecyde Thank you for reporting the problem. After some googling, I found issues like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625752; is your issue the same?

Or is there a good reason to stick with accept4?

Yes. I would like to preserve the use of accept4 whenever possible. The reason is that I am afraid we might see performance decrease if not using accept4, since we would need to take a mutex lock while calling accept and fcntl.

Regarding your issue, I have written and merged #527; you can now explicitly disable the use of accept4 by running CMake with -DCMAKE_C_FLAGS=-DH2O_USE_ACCEPT4=0.

Ultimately, we should automatically detect within CMakeLists.txt whether if accept4 is usable on the host. My understanding is that it could be run using try_run command. If you (or anybody else) could come up with such an PR, I am more than happy to review it.

diecyde commented 9 years ago

For my implementation the define is perfect, as I am cross compiling it is very hard to detect in compile-time if the function is available at all.

An try_run might work when building for an normal environment. I have created an simple test application which will fail when the function is not implemented.. I have tested this also on my cross build platform to confirm its result....

On 09/28/2015 06:24 AM, Kazuho Oku wrote:

@diecyde Thank you for reporting the problem. After some googling, I found issues like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625752; is your issue the same?

Or is there a good reason to stick with accept4? Yes. I would like to preserve the use of accept4 whenever possible. The reason is that I am afraid we might see performance decrease if not using accept4, since we would need to take a mutex lock while calling accept and fcntl.

Regarding your issue, I have written and merged #527; you can now explicitly disable the use of accept4 by running CMake with -DCMAKE_C_FLAGS=-DH2O_USE_ACCEPT4=0.

Ultimately, we should automatically detect within CMakeLists.txt whether if accept4 is usable on the host. My understanding is that it could be run using try_run command. If you (or anybody else) could come up with such an PR, I am more than happy to review it.

Reply to this email directly or view it on GitHub: https://github.com/h2o/h2o/issues/524#issuecomment-143638994

kazuho commented 9 years ago

@diecyde

For my implementation the define is perfect, as I am cross compiling it is very hard to detect in compile-time if the function is available at all.

Glad to hear that the fix is sufficient, and I agree that compile-time detection work in case of cross compiling.

Will mark this issue as FAQ now that it is a solvable issue by using the define.