Show HN: A minimalist event-driven (epoll) framework

If you put production cert & key to config (see README), warning disappear.

Thanks for the report!

P.S. See updated status of issue #2

Last week I wanted to comment about a bug on HN, then I realized it's more constructive to open up an issue on their Github repo.

I promise to factor out fixed point math into a separate project in case when it evolves.

(Of course, anyone distributing this project will need to comply with the terms of the GPL since it contains GPL-licensed code.)

See http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean and http://www.gnu.org/licenses/license-list.html#ISC

Here is a reason, why I did not choose another frameworks:

[1] It's hardly a framework, it's just a loop;

[2] A good event-driven framework. But it's not a complete solution. For example, there is no SSL support, no HTTP 1.1 support, no config parser, no modularity;

[3] Really good event-driven framework. But it's a big code-base. And again it's not a complete solution (see previous);

[4] I like libevent. I read repeatedly libevent source. Euclid inherited a few things from libevent (nothing special, but for example, how it works with OpenSSL API). Bot it's a big code-base. And there is a lot of logic intended for handling many connections. But my trading bot will not work with a lot of connections. I don't need that logic at all;

[5] It's a loop. I agree it's a good loop. But I need much more (in relatively small code-base!);

In other words, I needed small, cute and fast solution that satisfy my needs (trading bot).

YC HN inspired me a lot, a minimalist, cute and exactly what I want.

1. suppose there are two layers L0 and L1;

2. also there are an object O1 of type T which is used by L0, but pointer A1 to O1 is stored in context C at L1;

3. suppose an object O1 was freed, but after a while an object O2 was created at the __same__ address A1;

4. suppose a context C still has a pointer to A1 as a pointer to an object ____O1____;

5. but A1 doesn't have __O1__ anymore, O1 was freed, right now, A1 contains an object O2;

6. suppose after a while, L1 call API from L0 and pass A1 as a pointer to an object O1. OOPS! We have a bug at this point and we don't even know about it!

You may tell that it's unusual situation when O2 created exactly at the same address where O1 was stored. But I can answer that L1 may store objects on the array, say `T Os[100];` . In this case that situation is very possible.

So I solved this problem by introducing PTRID. In short, ptr_id_t contains address and unique id which is incremented globally.

So using PTRID at stage (6) I can catch a bug! See the code.

Note that, PTRID is intended to using for intra-layer calls. Don't use PTRID everywhere because it's a bit costly. Use it for intra-layer calls (i.e. between L0 and L1).

I like the following analogy:

1. memory address space is one-dimensional space.

2. but objects created and freed over the time!

3. so it's not really good to use one-dimensional pointer in two dimensional space!

4. that's why PTRID can be imagined as two-dimensional pointer, i.e. a pair (A, T). Where A is address, and T is time (i.e. global ID in my code).