First, I'm glad that someone is interested in an alternative server-core
of GNU Artanis. To gain more interestes, let me CC this mail to
address@hidden.
Here's my short answer:
I'd like to make GNU Artanis more general to support replaceable HTTP
server-core as a plugin. This requires standardize the low-level APIs,
which implies bigger works. But it's worth to go.
FWIW, there're some points that we should care about:
1. Ragnarok is co-routine based, so the current GNU Artanis has no
support for multi-threading. That is to say, no any locks. However, I'd
like to support multi-threading server-core as well. And I wrapped the
low-level data accessing with an abstract layer, so that we may add
locks without changing too many codes.
2. I've read a little libuv code before, the exported APIs seem not
general enough for us. I don't remember it exactly, but I've ever taken
a look at it for other purpose, finally we have to choose libevent.
3. I hope the folks who is interested in multi-threading server-core
start to research it. But I'd recommend not so hurry to make the hands
dirty, it's better to discuss in address@hidden first.
4. For FFI part, I have a macro in (artanis utils) that I'm using for
binding libnss currently:
https://gitlab.com/NalaGinrut/artanis/blob/master/artanis/utils.scm#L1594
The usage is simple:
-----------------code---------------------
(eval-when (eval load compile)
(ffi-binding "libnss3"
(define-c-function int NSS_Init ('*))
...
))
-----------------end----------------------
Then there's %NSS_Init, one have to do some validation to write a
function like nss:init or else.
4. I'll write an article about the roadmap of GNU Artanis-1.0. There'll
be more details about the plan. (Not only server-core).
I would like to work on libuv based core for artanis. I am not much of a guile
programmer but I do know C programming language reasonably well. However,
I would need some help as to how to layout this project.
I would like to run an event loop and run multiple threads but threads won't
share data. One thread will listen on the socket and assign work to worker
threads. Threads won't share any global data. So there will be no need of
locks. They will communicate to each other using message passing much