As SpikeX already pointed out calling a co-routine recursively might not be a good idea. Using Singletons for global Behaviour and states is a common software architecture. However, you can only start Coroutines from MonoBehaviours and you can't use the "correct" singleton pattern, as you are not supposed to call or change the constructor of a MonoBehaviour.

There are several ways to write a "pseudo-singleton" that is a MonoBehaviour to use with Unity.

public class EasySingleton {
  private static EasySingleton instance = null;
  public static EasySingleton Instance { get { return instance; } }

  void Awake() {
    instance = this;
  }
}

That's the easiest way. However you will have to attach this to a GameObject manually in your Scene.

public class AdvancedSingleton : MonoBehaviour {

    private static AdvancedSingleton instance = null;
    public static AdvancedSingleton Instance { 
        get {
            if (instance == null)
            {
                Debug.Log("instantiate");
                GameObject go = new GameObject();
                instance = go.AddComponent<AdvancedSingleton>();
                go.name = "singleton";
            }

            return instance; 
        } 
    }
}

The advanced version will create its own GameObject and attach itself to it as soon as you call it for the first time. This is very convenient and keeps your scene small in the editor. You could also implement something that will remove the object from you scene once it isn't needed anymore (e.g. the coroutines have finished.)

I don't know why you're getting errors, but I see a lot of potential problems with this script. Let me point them out, and we'll hope that one of them was the problem.

• I wouldn't call a coroutine from within a coroutine. Use a while(true) loop instead. It won't freeze your game because of the 1 second wait time. I do this all the time.
• I don't think you implemented the Singleton pattern correctly. See the correct C# example here.. Your constructor needs to be private (and empty!), and you need a static reference to the Singleton class.
• I don't think the singleton pattern will work for game objects that derive from MonoBehaviour. In fact, it's actually recommended that you DON'T have a constructor, and instead use Start() or Awake() for initialization. I can't even begin to wonder what kinds of problems you'd run into if you had a singleton attached to a game object.
• If you went into a bit of detail as to why you thought you needed a singleton, someone here might be able to recommend the correct way of doing what you're trying to do.

to make the Advanced singleton work,

in the start method, add a call to

DontDestroyOnLoad(go);

then, in the awake method add

if (instance)
    Destroy(gameObject);

instance = this;

when using writing public methods, be sure to add "Instance." to your variables. Also, make sure your public methods are static like this:

static public void someMethod()
{
   Instance.someVar = 100;
}

Beware that i may have made a few mistakes/type-os, but this is how I have my singleton that uses co-routines setup, and it works as it should. If anybpdy sees a real issue with this, speak up, so we can get this solved once and for all.

BTW, I learned this code from looking at other peoples code, so its my turn to pay it forward.

Purely for convenience:

In almost all projects: it will be the case that you will have an empty game object attached on your opening scene, for clarity let's call it "holdAll".

"holdAll" is persistent throughout the game.

Attached to that, you will have many files such as Shopping.js, Analytics.js, Calculations.js .. etc etc

Each of those uses coroutines. So they really are best as "normal" scripts attached to an game object.

Again, it's inevitable that almost every Unity game has an empty game object ("holdAll") which is persistent throughout the whole game, and you use those various

I've never seen a Unity project that does not have that.

So, this is all great and normal. But, each time you want to use a routine from shopping.js, you need to make a local variable which, annoyingly, you have to hook to shopping.js on holdAll.

Of course, it's much easier to just call ordinary static libraries, like when you use Mathf or the like.

Is there a solution?

Yes, here's what I do. Make a tiny little class called say "grid":

class grid
    {
    static var shop:Shopping;
    static var etc:Etc;
    static var etc:Etc;

    private static function grid()
       {
       shop = GameObject.Find("holdAll").GetComponent(Shopping);
       etc = GameObject.Find("holdAll").GetComponent(Etc);
       etc = GameObject.Find("holdAll").GetComponent(Etc);
       }
        // nb, grid() is indeed magically called (once only)
        // when one of these vars is first accessed - 
        // you need do nothing, just use the vars at will.
    }

then from anywhere at all in your project,

with no further effort,

you can just write

grid.shop.buy(..);
grid.shop.sell(..);
yield grid.shop.showDialog(...);
yield grid.shop.interactionUser(...);
x = grid.shop.count;

and so on. Same for all the others (Shopping.js, Analytics.js, Calculations.js etc etc)

I want the convenience of just being able to say

yield shop.whatever();

anywhere in the project WITHOUT needing an annoying hooked-up local variable "shopit" which leads to holdAll-Shopping.js.

But in my opinion there's just no really good, bulletproof, way to make a static/singleton/etc, where it's a "normal" coroutine-based Unity object.

So ... for me, this seems to answer all those needs. The only downside is effectively one extra "." when you type grid.shopping.

Seems to work ok ?