timers are not getting satisfied in order

Posted by Fiendish on Sun 28 Feb 2016 03:56 PM — 9 posts, 27,763 views.

Fiendish USA Global Moderator Sun 28 Feb 2016 03:56 PM #0

Following http://mushclient.com/forum/?id=12915&reply=44#reply44 I've had to start using DoAfterNote(0.1, foo) instead of Note() or print(), because otherwise my prints just never show up.

Except now this happens:

for i=1,30 do DoAfterNote(0.1, i) end

Quote:

1
17
18
19
20
21
2
3
4
5
6
22
23
24
25
26
7
8
9
10
11
27
28
29
30
12
13
14
15
16

Timers in the same time slot should be kept in stable creation order.

Looking at timers.cpp and methods_timers.cpp, it seems like perhaps timers should be primarily pushed on the end of a sequential structure (I say vector not list if we iterate constantly and change infrequently) instead of added to a map, and have name->index lookups stored in the map.

Fiendish USA Global Moderator Sun 28 Feb 2016 08:13 PM #1

Fiendish said:

Looking at timers.cpp and methods_timers.cpp, it seems like perhaps timers should be primarily pushed on the end of a sequential structure (I say vector not list if we iterate constantly and change infrequently) instead of added to a map, and have name->index lookups stored in the map.

This would also let you get rid of CTimerRevMap, and all of the calls to SortTimers (which don't actually sort timers, I guess, lol), which I'm pretty sure you could get rid of anyway by just assigning timer key to the timer's strLabel field in DoAfterSpecial.

Nick Gammon Australia Forum Administrator Sun 28 Feb 2016 08:40 PM #2

Quote:

Except now this happens

I thought that might happen, which was why I felt a twinge of doubt when you suggested it.

Timers are stored in a map (derived from CTypedPtrMap), which (unlike STL) does not guarantee that results are returned in alphabetic order.

Plus, even if it was, un-named timers would end up at the end, not in timer sequence.

For your idea to work timers would need to be in a data structure by expected expiry time, followed by order of submission. There also needs to be a way of getting at one by name, and also by pointer.

What I thought you might do is simply insert messages into the tail of a table, and have your own timer pull them out every 0.1 seconds or so. That guarantees that those messages are displayed in submission order.

Fiendish USA Global Moderator Sun 28 Feb 2016 09:07 PM #3

Nick, I keep accidentally editing your posts instead of quoting them. :\ I tried to put it back as it was.

Nick Gammon said:

For your idea to work timers would need to be in a data structure by expected expiry time.

I don't think so. You're already iterating through, essentially, in what may as well be random order because CMap steps neither in insertion order nor in key order. The timers aren't firing in the wrong time slot, so that part is ok, so you just need to make sure that the new may-as-well-be-random order preserves insert order. You get that by tacking them on the end of a simple sequential structure.

Quote:
There also needs to be a way of getting at one by name, and also by pointer.

That's easy to do by still having a map that just associates name with sequential index.

Quote:
What I thought you might do is simply insert messages into the tail of a table, and have your own timer pull them out every 0.1 seconds or so. That guarantees that those messages are displayed in submission order.

What, everywhere? I'd rather make timer order predictable. :)

Fiendish USA Global Moderator Sun 28 Feb 2016 09:19 PM #4

I can send a pull request on github, except that I don't currently have a Windows build environment, so I'll be doing it blind. ^_^

Nick Gammon Australia Forum Administrator Mon 29 Feb 2016 05:41 AM #5

I'll look at converting the timer maps into an STL map. I never liked the Microsoft classes anyway. :)

Nick Gammon Australia Forum Administrator Mon 29 Feb 2016 08:39 AM #6

Fiendish said:

Except now this happens:

for i=1,30 do DoAfterNote(0.1, i) end

Quote:

1
17
18
19
20
21
2
3
4
5
6
22
23
24
25
26
7
8
9
10
11
27
28
29
30
12
13
14
15
16

Strange, I got:

Fiendish USA Global Moderator Mon 29 Feb 2016 12:28 PM #7

Yeah. I think the order for CMap will be based on hash key, which is going to be different every time.

If you use an STL map, remember that iteration order needs to match insertion order, not some arbitrary sort on name, so you'll need to either not index by name or make your own compare function.

What is needed really is a "linked hashmap" like boost::multi_index (except "lol @ adding boost to a project for one measly data structure").
Which I guess you could mimic with one of


std::map<insertion_sequence_t, std::pair<string, CTimer*> > sorted_forcefully_by_insertion_sequence_so_iterate_over_me_to_check_timers;
std::unordered_map<string, insertion_sequence_t> use_me_to_find_by_key;


std::list<CTimer*> sorted_naturally_by_sequence_if_all_new_timers_are_pushbacked_so_iterate_over_me_to_check_timers;
std::unordered_map<string, std::list<CTimer*>::iterator> use_me_to_find_by_key;

The latter has the benefit that ordering constraint is natural and can never overflow, whereas, at least in theory, insertion_sequence_t has a finite capacity for sequencing. Probably not a realistic concern.

Though this single header file (MIT license) also looks nicely hassle-free if it works. https://github.com/nlohmann/fifo_map

Nick Gammon Australia Forum Administrator Mon 29 Feb 2016 07:35 PM #8

A custom compare function is simple to write, I'll take a look at it.