BSD Support: Question about core lib implementation

[SmartArray]

Dear maintainers and contributors. I am currently implementing kqueue support, and I have made some decent progress. There is however something I need help with as I don't understand what is supposed to happen in the core code. Perhaps somebody can give me insight on the following:

Setup I have set up a basic Router which serves a route with the path /A.

endpoint->setHandler(router.handler());
endpoint->serveThreaded();

When using curl to do the request, the handler is successfully called. However, the response hangs:

*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 58269 (#0)
> GET /A HTTP/1.1
> Host: localhost:58269
> User-Agent: curl/7.54.0
> Accept: */*

I saw that Transport::onReady (transport.cc) was called successfully. First of all, the request was parsed correctly. That is, handleIncoming(peer) was called and the parser was attached to the peer struct. That looked good so far.

My question: What is supposed to happen after that?

What I saw in my development branch:

1. handlePeerQueue() is called, the parser was attached successfully
2. handlePeerQueue() was called again
3. entry.isReadable() gets called, which calls handleIncoming(peer)
4. handleWriteQueue() was invoked. This method writes places a WriteEntry into toWrite (https://github.com/oktal/pistache/blob/73f248acd6db4c53e6604577b7e13fd5e756f96f/src/common/transport.cc#L365)
5. Nothing happens anymore.

I think overall I have made great progress implementing kqueue support. But I didn't have any significant progress today, as I don't understand the workflow of the Transport class. Can anybody help explaining how the response will actually be triggered?

[dennisjenkins75]

Hello!

FreeBSD support? Cool! Someone else recently posted that they are working on MacOS support as well. Thank you for working on this. Sadly though, I am only a "guest maintainer", and I've never dug into the core networking code. Its very... odd.

(This is going to sound so ancient..., like 1970's), add some logging / printf to the code code, and test it on Linux, see what it does.

[SmartArray]

That was me! If we add the appropriate kqueue calls, BSD and MacOS will work!

I thought about the printout-comparison thing too. Just hoped there would be someone who could guess why and where it‘s hanging. LLDB doesn‘t give me a hint at all :(

[SmartArray]

@dennisjenkins75 I tried your approach, it gave me exactly the same results. Additionally, in the end, Transport::onReady() was invoked on Linux. But not on MacOS. Thus, on MacOS the response is never written back to the socket fd. At least I know I am on the right path.

Seems like I have already come far!

EDIT Oh no! Of course the hang was caused by the Epoll events. The bad message here: There is an issue with how kqueue works. And I am not sure if I can fix that without altering the Worker logic.

[dennisjenkins75]

Once you get something working, please extend travis coverage to at least one recent version of FreeBSD. I would hate to break FreeBSD support due to some other code change.

[SmartArray]

That‘s true. Great idea!

[ghost]

@SmartArray How is your progress?

[SmartArray]

@SmartArray How is your progress?

I stopped working on it some months ago. It compiled well, and I thought it would be working. However, the tests didn't complete successfully; multiple things were very odd. That being said, I don't think it is worth it to port this library to BSD.

However, if someone wants to try, feel fee to use my existing work (which I spent more than 10 hours on)

As an alternative I have found (but not tried) https://gitlab.com/eidheim/Simple-WebSocket-Server

Benchmarks look super solid.

[ghost]

Why is it suddenly not worth to port it? Only because it is hard?

[SmartArray]

IMHO, it doesn't make sense to port it. See, my work was highly theoretical. Kqueue just doesn't use file descriptors and making it compatible to timerfd/pollfd should already be done in the initial planning.

Moreover, I ran out of time and need to care about my personal projects again. As far as I understood, the original developer isn't here anymore, he could have answered many questions that I had in the past.

But feel free to continue with my work 😊