Any ideas or suggestions?

[12k]

Well, the idea is to sleep all the way up until the next event, to try to save a lot of extra checks that aren't needed. So the events that only occur like once a week wont need to be taking up anything extra until its their time to run. Instead of checking if its time for guild war every 10 seconds for a whole week, just have a idle thread. Not sure if this is a great idea or not, but this is my implementation of the idea. If you have any thoughts or suggestions please shoot . Would also like to hear any of your all's solutions to things like this.


EventPool.cs

using System;
using System.Threading;
using System.Collections.Generic;
namespace Base
{
    public class EventPool
    {
        private IEvent[] Events = new IEvent[2];
        private byte NextEventToExecute = 0;
        public EventPool()
        {
            Events[0] = new Events.GuildWars_Start();
            Events[1] = new Events.GuildWars_Stop();
        }
        public void Start()
        {
            for(byte i = 0; i < Events.Length; i++)
                if(Events[i] != null)
                    if (DateTime.Now < Events[i].StartTime && DateTime.Now > Events[i - 1].StartTime)
                    { NextEventToExecute = i; break; }
            while (true)
            {
                if (Events[NextEventToExecute] != null)
                    Events[NextEventToExecute].Execute();
                NextEventToExecute++;
                if (NextEventToExecute > Events.Length)
                    NextEventToExecute = 0;
                Thread.Sleep((int)(Events[NextEventToExecute].StartTime - DateTime.Now).TotalMilliseconds);
            }
        }
    }
}

IEvent.cs

using System;
namespace Base
{
    public interface IEvent
    {
        DateTime StartTime { get; set; }
        void Execute();
    }
}

[pro4never]

I kinda like the idea behind it but not the implementation...

Using one thread that sleeps for long time should be a perfectly viable way to deal with things that don't happen that often (say... every hour or couple times a day?).

That being said I would not write it how you have it right now.

Example complaints with your implementation.


#1: Arrays. No easy way to add/remove items from the thread. You want something that can easily be controlled

#2: No/Few helper methods. Adding a new event should re-organize the list so that the first item in the list is always the next item to be processed

#3: No way to handle events being added when a sleep has already been called. Example.. You start the server and only have 1-2 events in there that may not take place for say... a a day or more. If you want to add in another event in say an hour, it will not ever try to run that event until the first sleep has passed (possibly days). You need a way to control this properly.


I'd say that the easiest and most practical way to do this would just be to have the thread run say... once a minute. That's little to no strain on your server and it also opens up the thread to do MANY more things.

Think of all the things that you would want to have run with accuracy to the minute..

Lottery resets, any events (quiz, pk, gw, etc), system messages, etc.

All of these can be combined into one simple thread that just says "Hey, this item is in my list of actions to perform and should be performed this minute, lets run it!". It's easy to deal with and can be expanded to take care of just about anything you want.

[12k]

Hmm, very good idea. I just made this one for events that are like weekly. As far as this class goes, I didnt have any intensions on things being removed, because all of them would always be the same date and time. I just order them by the datetime as I add them to the array. But if anyone else wanted to expand on this idea, i can certainly see the benefit of adding the add/remove events.


#edit, this is kind of a run-off from the idea you gave me.

[BaussHacker]

1. Why do you use an interface?
2. Multithreading is your friend.

[12k]

1. That way I can easily do different things with Execute() when the event is started.

2. Why multithread when the purpose is to have a thread that sleeps up until its time for a event to be called, then goes back to sleep until its time for another.

#Edit: Ah sorry, didnt realize it didnt show this was running on a separate thread. I have a different handler that runs this on its own thread.

[BaussHacker]

Originally Posted by 12k

1. That way I can easily do different things with Execute() when the event is started.

2. Why multithread when the purpose is to have a thread that sleeps up until its time for a event to be called, then goes back to sleep until its time for another.

#Edit: Ah sorry, didnt realize it didnt show this was running on a separate thread. I have a different handler that runs this on its own thread.

Interfaces are used to inheritance, It would be more reasonable making it a class.

The Thread.Sleep will sleep the current thread, so that means the main thread and it will freeze EVERY single procedure untill it's finished. That's why you use multithreading in this case. :P

[pro4never]

Originally Posted by BaussHacker

Interfaces are used to inheritance, It would be more reasonable making it a class.

The Thread.Sleep will sleep the current thread, so that means the main thread and it will freeze EVERY single procedure untill it's finished. That's why you use multithreading in this case. :P

This entire system would be on its own thread, thats what he was saying xD.

[Korvacs]

If the entire system is to be contained on 1 thread then you would need to have something that does like

while(true)
{
     if(EventsWaitingToStart.Count > 0)
     {  
           StartEvents();
     }

     if(EventsRunning.Count == 0)
     {  
           Thread.Sleep(1);
           continue;
     }
     else
     {  
           //Run Events
     }
}

This wont use any CPU at all in the grand scheme of things, plus it allows for on the fly creation of events, unlike Thread.Sleep(<insert 5 days of sleep time>);

And if you have to bring the server down or it crashes it equally doesn't need modifying.