Author Topic: FluffOS 3.0-alpha7.4  (Read 8493 times)

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
FluffOS 3.0-alpha7.4
« on: November 06, 2013, 12:56:15 AM »
Download at: https://github.com/fluffos/fluffos/releases/tag/fluffos-3.0-alpha7.4

Sorry for the delay,  it's time for a new release before things get out of hand.  this version has been running in biggest china mud for almost a month, no stability issues,should be good to go.

Also, this includes cygwin compile and freebsd fixes, which is not yet complete but with proper knowledge you can now get them to compile under gcc 4.8.

Cheers!


3.0 vs 2.0 Summary

https://github.com/fluffos/fluffos/blob/next-3.0/ChangeLog.fluffos-3.x

FluffOS 3.0-alpha7.4
New features

PACKAGE_DB: MYSQL NewDecimal Type This is needed in my system for read a column SUM(xxx) in a SELECT. (Zoilder)
Various time tracking efun uses real world time as it should be.
Driver now calls reclaim_objects() automatically.
Default evaluator stack has been increased to 6000. Bug Fix:
Sending string over UDP port now doesn't contain trailing \0. Misc
Moved many internal options to options_internal.
Optimized funciton lookup cache, also increased default cache size. (CPU saver!)
New tick_event loop and callback tree implementation.
Adjusted backend() loop, should have no behavior change.
Adding back 32bit compile mode test.
various compile fixing, althrough not complete, but should be compileable under CYGWIN64 and freebsd using gcc 4.8.
FluffOS 3.0-alpha7.3

User command execution is now integrated into event loop. (at least 10% CPU decrease and better fairness among users).
Fixed unique_mapping() crash when callback returns new objects/array etc.
Fixed memory corruption issue with unsupported TELNET environment negoation.
Fixed memory corruption when reading 0 length file.
restored USE_ICONV in auto testing.
Moved many options into options_internal.h, all the local_options override still works. edit_source will print out "extra" defines local_options contains. This pave the road for reducing complexity of options.h in the future.
ALLOW_INHERIT_AFTER_FUNCTION is now default, no crash anymore.
Previously if a user object is destructed, the message in the buffer would be lost. Now the driver will correctly send them out before terminating connection.
FluffOS 3.0-alpha7.2

unique_mapping() crash when callback returns a non-shared string.
move some outdated doc to /doc/archive.
some format change in EFUN/APPLY doc.
FluffOS 3.0-alpha7.1

disable_commands() change is reverted, not thought through.
enable_commands() now accepts a int instead (see 3.0 vs 2.0)
FluffOS 3.0-alpha7

Check c++11 capability during configuring.
new LPC predefine "CXXFLAGS."
Fixes cmud/zmud problem with TCP_NODELAY with MCCP.
new debug macro "-dadd_action" to show add_action related logs.
disable_commands() now accepts one int argument. (see 3.0 vs 2.0).

Offline Holyavenger

  • Friend
  • **
  • Posts: 92
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #1 on: November 06, 2013, 09:55:04 AM »
Thanks for keeping the Mud Driver torch burning. I'll try it and report back with results.

Offline DarKWateR

  • BFF
  • ***
  • Posts: 104
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #2 on: November 07, 2013, 09:03:07 AM »
Thanks for this new version!

I'm testing, for now i saw two "bugs":
1- News Call_out: I have a cron in my mudlib. When load for first time, it executes a call_out with the time in seconds to the next block of execution (5 minutes).
    For example:
      Time: 2013/11/07 15:23:50
      Block: 5 minutes.
      Executes a call_out with 70 seconds (15:25:00)

   The problem with this driver is that sometimes, it adds call_out with 69 or 71 seconds, because at that moment, variable current_virtual_time is distinct real_time and executes call_out 15:24:59 or 15:25:01.

   In my case, i've modified in call_out.c, this line:
      cop->target_time = current_virtual_time + delay;
   by
      cop->target_time = get_current_time() + delay;

  This change works for this example.

   Surely this solution isn't valid. Any ideas about it?

2- The driver freezes about one hour after reboot. There aren't error messages in logs, is only that the driver freeze, doesn't accept any new logins, etc. For now, i couldn't reproduce it, i haven't idea about it.


Thank you very much.

Sorry my bad english.

Offline quixadhal

  • BFF
  • ***
  • Posts: 629
    • View Profile
    • WileyMUD
Re: FluffOS 3.0-alpha7.4
« Reply #3 on: November 07, 2013, 12:01:21 PM »
call_out() isn't really designed to operate in real-time.  MudOS/FluffOS has a virtual time system that tries to adapt for situations where resources are limited, by ensuring that if you do a call_out() in 5 seconds, it happens at least 5 seconds later.

If the call_out() is happening early, that is indeed a bug.

As a suggestion to add to the pile, perhaps an extension that provides a call_out_realtime() or similar would allow for scheduling of callouts at a particular point in time (or as close to it as possible, given resource load).

That way, for example, you could specificy that an event happens at 12:00am every day, even if your system were heavily loaded and virtual time ended up being several minutes behind real time.  Obviously, on a heavily loaded system it might still be a few second off, but it wouldn't end up behind a huge backlog.  Also obviously, you don't want to use that for anything that isn't timing critical, or you'll just bog everything down further. :)

Offline DarKWateR

  • BFF
  • ***
  • Posts: 104
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #4 on: November 07, 2013, 12:26:14 PM »
If the call_out() is happening early, that is indeed a bug.

Sorry, I was wrong, only executes before (1 second +/-)

Thank for your response!

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #5 on: November 07, 2013, 01:50:44 PM »
you mean "after", right? call_out can only happen late .

This is the default behavior for a long time.

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #6 on: November 07, 2013, 01:55:59 PM »
you can run driver with ./driver config -d and inspect *all* call_out execution log.

Offline DarKWateR

  • BFF
  • ***
  • Posts: 104
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #7 on: November 07, 2013, 03:34:39 PM »
sorry, call_out is ok, is only that in my mudlib i use time() for calculate number of seconds for call_out, but driver use current_virtual_time, and if that virtual time is distints, that difference causes that call_out start with some second difference.

thank you very much and sorry for the bad example.

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #8 on: November 07, 2013, 03:36:25 PM »
you should use find_call_out() etc to get the correct pending time.  It uses virtual time as intented.

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #9 on: November 07, 2013, 03:54:43 PM »
call_out() isn't really designed to operate in real-time.  MudOS/FluffOS has a virtual time system that tries to adapt for situations where resources are limited, by ensuring that if you do a call_out() in 5 seconds, it happens at least 5 seconds later.

If the call_out() is happening early, that is indeed a bug.

only true in the driver's virtual time, if that happens to be 5 seconds behind the real time, it'll happily do your call_out in the same real time second, which is why on any properly running mud with little lag you can actually use time() calculate when the next whole hour is and set a call_out to trigger at that time, and it'll run when the virtual time reaches that time, if there's no lag at that moment it'll be the time you wanted, and if there is lag, there's nothing that could make it run on time anyway, or at least not until we get multithreading, that's why time() returns virtual time so log files will look nice and acurate, and there is real_time() for when the actual time matters, they should be the same most of the time.

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #10 on: November 07, 2013, 04:02:04 PM »
wow, I didn't know we have real_time() efun. Looks like I should revert my time() change to make it use virtual time again.

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #11 on: November 07, 2013, 04:11:34 PM »
Also, in current driver it is almost not possible to have more than 1 sec difference.  So this hardly matters.

The problem with call_out, as previously discussed, is that it has two distinct use cases

1) call with virtual time based delay. ( many call_out(2) is expected to run once two heartbeat for example)
2) call with absolute wall-time delay. (call_out(3600) expect to run on exact full hour mark)

The current driver only support use case 1), while people has been trying to use it to simulate 2). which is not going to work. I plan to implement a call_out_realtime()  , this will free up driver to allow virtual time drifting and tolerant more delay without other consequences (like missed heartbeat, missed callout, etc).

Offline chaos

  • BFF
  • ***
  • Posts: 291
  • Job, school, social life, sleep. Pick 2.5.
    • View Profile
    • Lost Souls
Re: FluffOS 3.0-alpha7.4
« Reply #12 on: November 07, 2013, 08:31:08 PM »
The virtual-time smoothing mechanism that Wodan describes is basically why my MUD's performance improved dramatically when I introduced a lib-level mechanism for requesting interval callbacks (a la JavaScript setInterval) that are implemented via heart_beat() and whose handling philosophy is best-effort rather than guaranteed-N-calls-over-N/interval-seconds.  The more heavily your lib uses call_outs, the more it becomes a superb mechanism for generating uncontrollable self-similar lag spikes.

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #13 on: November 07, 2013, 11:03:41 PM »
Mudos/Fluffos always tries to catch virtual vs real time,  that's why we have these cpu issues. The root cause is when things slows down, driver tries to do more work, by executing multiple heartbeat and call_out in a loop, because it want to catch up.

This is fundamentally wrong. Virtual time has little or no use to catch up with real world. Things that need to corelated to real world time, need to use real world time instead.

In current driver, the only choice is like what you describe, use lib to simulate a real-world clock by keep readjusting the delay time.But the true solution is to just provide a driver function allowing these two distinct function to co-exist and stop catching-up virtual time all together.

Offline DarKWateR

  • BFF
  • ***
  • Posts: 104
    • View Profile
Re: FluffOS 3.0-alpha7.4
« Reply #14 on: November 26, 2013, 04:50:51 PM »
A little bug with call_tick_events?

In previous version, if i add a new call_out B with 0 delay from a active call_out A, the new call_out exec after right after call_out A,

In last version, call_out B exec in next call_tick_events executions.

Example:
void heart_beat(){
call_out("A",0);
}

void A(){
call_out("B", 0);
}

void B(){
}

Order Execution in previous version:
Heart_beat
Call out A
Call out B

Heart_beat
Call out A
Call out B

In last version:
Heart Beat
Call out A

Call out B
Heart beat
Call out A

In my driver i've modified call_tick_events for return number of events executes and then while(call_tick_events()); but it causes perhaps a infinite loop if add infinite call_out with 0 delay in a loop (i can't test now)
« Last Edit: November 26, 2013, 05:00:57 PM by DarKWateR »