N
7 local karma · 7 contributions here · active since May 2026
Async/Await in C?
The question explains itself, but for context:
I am writing an Over-Engineered HTTP server for fun's and learning's sake, and I have hit a conceptual roadblock.
Currently, the server works thusly:
One (1) thread sits on a port and accept()s incoming requests and adds them to a queue, then pthread_cond_signal()s a condition that...
... Four (4) threads (request handlers) are pthread_cond_wait()ing on, one of whom will pick up the request and parse it.
Here comes the issue:
Similar to that the server simply adds each request to a queue, I want each request handler to, once it's parsed a request, hand it off to some HTTP_<method> function, then pick up the next request from the queue, only returning to the original point of execution (the point where HTTP_<method> was called), where it then returns a response.
The only two ways that comes to mind of doing this, one of them require N more threads sitting on another queue, which I feel weird about, and the other requires some Macro Fuckery that I found on a Github repository then lost, so Idk if it even is feasible.
How do I go forward from here?
TL;DR: Async Await for C; good, bad, or disgustingly ugly? Potential other solutions?
Join the discussion
You must be a member of /c/programming to comment.
10 local karma · 10 contributions here · active since May 2026
I would just pass a function pointer in that gets called whenever a request matches it. If the user thinks what they're doing is heavyweight enough, let them delegate it to a thread pool themselves inside the callback.
Another approach is to use something like FastCGI; either make your application a much-simpler FastCGI client and let NGINX handle all the HTTP stuff, or make your HTTP server handle client requests by delegating them to FastCGI clients.
▲
2
▼
5 local karma · 10 contributions here · active since May 2026
Better than a direct function pointer is a pointer to a function pointer, that identifies a function which takes the address of the function pointer as its first argument. The function may then be designed to accept the address of a structure whose first member will be the function pointer used to invoke the function, but may have whatever other members the function would need.
While it's common for event queueing systems to work with a (function pointer, void pointer) pair, and pass the void pointer to the function, bad things can happen if the function pointer and void pointer get out of sync. Having the function pointer be the first item in the event-state structure means that if the proper function pointer is placed in the event-state object, only one pointer will need to be stored in collections and it will always be in sync with itself.
9 local karma · 3 contributions here · active since May 2026
I want to make sure I understand
You're saying rather than a function taking a function pointer and an opaque user pointer, it takes a pointer to a structure that contains as its first member a function pointer (to ease casting? or just arbitrary?), along with whatever else the user needs (since it's their pointer to struct they control what the struct is?)
5 local karma · 10 contributions here · active since May 2026
Yeah. Basically it means that everything through which the pointer passes just has to deal with one pointer rather than two. Code passing a callbacks which doesn't need any per-instance data and doesn't want to spend RAM on one need to define a const static object holding the address of the callback function, but I like the semantics of using one "thing" of a type which exists in the language to encapsulate the necessary information.