Q: GTK# Application.Invoke Not Working I'm working on an application that has been tightly bound to GTK# by using Application.Invoke's through many of it's libraries. Unfortunately, we're porting the application (server type application) to a system with no window manager, so it currently crashed when we initialize GTK.
Application.Invoke doesn't seem to work without calling Application.Init, even when running my own GLib.MainLoop.
I am looking for a suitable replacement for Application.Invoke. How should I go about replacing Application.Invoke within the Libraries used by the application, so that I can remove the dependency on GTK ?
Note: I've proposed a refactoring to get rid of the GUI from the app and domain code and move it into a view, but that's been shot down for now. I'm basically trying to get it to run on a system with no window manager.

A: If it's async processing you want that doesn't need to happen on a specific thread, have a look at System.Threading.ThreadPool.QueueUserWorkItem. The main problem about this approach is that you have to ensure thread safety yourself.
If you do need it to happen on the main thread, you'll need to create a list of delegates to invoke and poll that list periodically on the main thread (or wait for something to be posted to it):
using System.Collections.Generic;
using System.Threading;
class Main {
    Queue<Action> actions = new Queue<Action> ();
    ManualResetEvent the_event = new ManualResetEvent (false);
    public void Invoke (Action action)
    {
        lock (actions) {
            actions.Enqueue (action);
            the_event.Set ();
        }
    }
    public void Poll ()
    {
        Action action = null;
        lock (actions) {
            if (actions.Count > 0) {
                action = actions.Dequeue ();
            }
        }
        if (action != null)
            action ();
    }
    public void Wait ()
    {
        Action action = null;
        while (true) {
            the_event.WaitOne ();
            lock (actions) {
                if (actions.Count > 0) {
                    action = actions.Dequeue ();
                } else {
                    the_event.Reset ();
                }
            }
            if (action != null)
                action ();
        }
    }
}


A: Application.Invoke basically works by keeping a list of delegates to run.
Each time the GTK main loop iterates it checks this list and executes anything it finds. It sounds like you need a background thread that loops like this.
That said, I can't imagine how or why you need this looped invoke on a non-graphical app, you would probably be just as well served by simply calling directly there and then. Eg:
public static class Application {

   public static void Invoke ( EventHandler dothis ) {
      if ( dothis != null ){ 
         dothis( null, null ); }
   }
}


A: Application.Invoke does not need to be replaced (at least for the version I am using). This was a misconception. Application.Inoke simply turns around and adds a delegate to GLib.Timeout, with the timeout set to 0, and returns "false", therefore only firing once.
Instead of getting rid of Application.Invoke, I attempted to find out why my delegates were not firing when using Application.Invoke without Appliation.Run or Application.Init. Keep in mind that I had already started my own GLib.MainLoop.
As it turns out, the Application's static constructor calls GLib.Thread.Init(), which is basically a timebomb. GLib's documentation states that GLib.Thread.Init must be called when using multiple threads, and that if GLib.Thread.Init is ever called, it must be called BEFORE any other GLib usage.
So, in the code I was working with, we added a delegate to GLib.Timeout after Application.Init, but before Application.Run, and before any calls to Application.Invoke. This means we were safe, because Application.Init would invoke the static constructor of Application, therefore invoking GLib.Thread.Init. This was good. However, when we removed Application.Init, and called Timeout.Add first, Thread.Init had not yet been called. This meant that if we called Thread.Init later, the threading, timeouts, delegates, etc, would choke.
Sure enough, Application.Invoke or Application.Run would invoke the static constructor of Application, which in turn would invoke GLib.Thread.Init. This caused the problem.
TLDR;
Long story short, make sure you invoke Application's static constructor before using Timeout.Add in your application code. Don't call Glib.Thread.Init manually, because calling it twice on Mono will make the application crash.
This is okay:
Application.Init();
Timeout.Add(0, delegate { return false; });
Application.Invoke(delegate { Console.WriteLine("Hey"); });
Application.Run();

This will ruin your life:
// Application.Init();
Timeout.Add(1000, delegate { return false; });
Application.Invoke(delegate { Console.WriteLine("Hey"); });
new MainLoop().Run();
//Application.Run();

But this is fine:
// Application.Init();
Application.Invoke(delegate {});
Timeout.Add(1000, delegate { return false; });
Application.Invoke(delegate { Console.WriteLine("Hey"); });
new MainLoop().Run();
//Application.Run();

