fluffos
fluffos copied to clipboard
fluffos
re-implement max_eval without posix timer
Is it possible to do this stuff without using this newish header file? One problem with it is it has also been relabelled utils.h in the newer libevent versions so it isn't always in the same place...
The driver depends on libevent 2.0, if 2.1 has backward compatibility issue we will have to adjust code and check for libevent 2.1 (I am not yet convinced to upgrade) .
I was looking at the documentation for the older libevent 1.4. I am wondering why we cannot just use a persistent ev_timerset ev_timeradd and ev_timedel setup?
I havnt tried it, not sure if that would work. because when LPC vm is executing, the eventloop wont be running.
how about using a separate thread and sleep it and use a mutex on the eval variable? and just have the sleep execute in a loop.
It should work, instead of a mutex we can just use an atomic variable.
On further investigation, I think I will just use std::steady_clock from
The current implementation apparently is way too CPU heavy under CYGWIN, i think I have to try again with a separate event loop thread
What I would suggest is to look at how DGD handles compilation under both UNIX and Windows. They use a native Visual Studio environment and just have the minimal code that needs to work differently under windows (sockets, signal handlers, etc). As such, you don’t need to depend on the Cygwin emulation environment, and should you want to debug the driver, you can do so with the native visual studio debugger.
Visual Studio Community Edition is free, BTW… so anyone running windows can use it.
Since FluffOS 3.x compiles with C++, it shouldn’t be an issue moving to Visual C++, you just wouldn’t use any of the .NET features.
Sent from Mail for Windows 10
From: Yucong Sun Sent: Saturday, October 7, 2017 12:57 To: fluffos/fluffos Cc: Subscribed Subject: Re: [fluffos/fluffos] re-implement max_eval without posix timer(#380)
The current implementation apparently is way too CPU heavy under CYGWIN, i think I have to try again with a separate event loop thread — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
The current build env depends heavily on linux utils, it's not a priority to remove them.
This is mostly done, however we should not check for outoftime on each instructions, just need to pick a good enough number.
Reverted due to performance issue, an new implementation should be thread based, but that's not going to be in v2019.1