I haven't really dug into it (though what I have seen looks pretty nice), but when I think "light-weight event-driven framework" I don't think "includes a fixed point math library".
At first glance it seems like there may be some semi-tangential stuff included here that might do best factored out into a separate project.
I agree with you. Before I published Euclid I thought about cutting "fixed point math library" from Euclid. But after a while I realized that it's a tiny bunch of macroses. And I decided: why not to give a little gift to algo traders.
I promise to factor out fixed point math into a separate project in case when it evolves.
I compared the author's Github username and the submitter's HN username and assumed that they were the same person. Though a private message is probably still a good idea.
This is a throwaway key that's used for tests.
But other people may miss it.
So I've explicitly marked these files and config cmds as test files and cmds.
Also, I put a warning msg to log and to README.
If you put production cert & key to config (see README), warning disappear.
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).
Right, thanks. It's a form of pointer virtualization basically.
To me personally this falls into the same domain as the "if (0 == x)" notation - it protects against a very specific type of rake that its proponents just happened to have stepped on at some point eariler on. I've been programming in C for over 20 years now and I have never had the issue you are describing. I understand it's possible, but then there's plenty more ways to shoot oneself with C pointers.
I worked (and I'm still working) on several big projects which wrote by different people, and by different companies, and at different time. I repeatedly noticed the same pattern where there is a limited linear array of contexts. For example, linear array of user contexts.
In this case, it's easy to create a new object in that array just after previous object was destroyed at the same slot (we called an index number in the user context array - slot).
I'm not sure I'd call this a refusal, they've only just released it and it was born from a personal project where they didn't need to create a generalized portable solution. This project may be useful to others as is which is probably why they released it.
The author has done nothing wrong. You can legally combine GPL-licensed code with code licensed under a GPL-compatible license. The author's code is licensed under the ISC license, which is compatible with the GPL.
(Of course, anyone distributing this project will need to comply with the terms of the GPL since it contains GPL-licensed code.)
Hey bro, I'm also building an event-driven trading framework except I went with ZeroMQ (for socket level pub-sub, rpc and push-pull) and Google Protobuf (for messaging serialization and shared service scaffolding across C, JVM and Python).
Granted, yours is one layer closer to the socket, so I hope that we are not trading the same securities so that your FIX messages will arrive faster than mine, ;)
Is there a reason why you didn't use another event-driven framework like picoev[1], ivykis[2], or the more popular ones like libuv[3], libevent[4], libev[5]?
Actually, Euclid is not just minimalist event-driven framework based on epoll. I just could not find a better short description. Euclid is an attempt of minimalist out-of-box solution based on event-driven architecture.
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.
26 comments
[ 14.2 ms ] story [ 2586 ms ] threadThanks for sharing.
At first glance it seems like there may be some semi-tangential stuff included here that might do best factored out into a separate project.
I promise to factor out fixed point math into a separate project in case when it evolves.
https://github.com/hal9000xp/euclid/blob/master/core/server....
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.
If nothing else, this might remind those who see it that you can leak private keys / passwords if you put then in source control.
Chris Poole described having this exact problem, in his recent post about 4Chan being hacked - AWS keys in the commit history. (http://chrishateswriting.com/post/84931829578/when-a-bad-day...)
If you put production cert & key to config (see README), warning disappear.
Thanks for the report!
P.S. See updated status of issue #2
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).
To me personally this falls into the same domain as the "if (0 == x)" notation - it protects against a very specific type of rake that its proponents just happened to have stepped on at some point eariler on. I've been programming in C for over 20 years now and I have never had the issue you are describing. I understand it's possible, but then there's plenty more ways to shoot oneself with C pointers.
In this case, it's easy to create a new object in that array just after previous object was destroyed at the same slot (we called an index number in the user context array - slot).
(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
I was trying to point out that the project's top-level LICENSE file, which makes no mention of the GPL license that the combined work must be under: https://github.com/hal9000xp/euclid/blob/master/LICENSE
(From your link "[GPL licenses] also permit distribution of such combinations provided the combination is released under the same GNU GPL version")
Granted, yours is one layer closer to the socket, so I hope that we are not trading the same securities so that your FIX messages will arrive faster than mine, ;)
[1] https://github.com/kazuho/picoev
[2] http://libivykis.sourceforge.net/man3/ivykis.3.html
[3] https://github.com/joyent/libuv
[4] http://libevent.org/
[5] http://software.schmorp.de/pkg/libev.html
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.