[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libuv based http server for Guile

From: Shiv Shankar Dayal
Subject: Re: libuv based http server for Guile
Date: Sun, 3 Nov 2019 13:18:06 +0530

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

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:
The usage is simple:
(eval-when (eval load compile)
(ffi-binding "libnss3"
(define-c-function int NSS_Init ('*))
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
like in

Shiv Shankar Dayal

reply via email to

[Prev in Thread] Current Thread [Next in Thread]