🚀 go-pugleaf

In article <1367@inria.inria.fr> rouaix@inria.inria.fr (Francois Rouaix) writes:
>Forbid() and Permit() work by incrementing and decrementing a counter
>(TDNestCount (sp?)) which tells the scheduler if the task may be switched
>or not. Now if you write too much Permit() (ie more than Forbid()) in the
>code, then the value in the counter might get negative. A later Forbid() will
>then have NO effect.
[...]
>Since this was so much pain to debug, I'll make a wish for 1.4 !
>I want that Permit() checks the counter so that it can never get
>negative (one MOVE is enough...).
>(Note how it is similar to some Lisps that allow superfluous closing
>parenthesis)

There is a problem with this, how is '1.4' going to know when Permit()s
should start permitting again, if the value didn't change?  The increment
decrement is a way to make sure that nesting is safe.  How about something
similar to:

	flag = Forbid();
	...
	Permit(flag);

When you call it, you get the current state, and when you restore it you
put back the previous state.  This is much like spl()'s in the Unix kernel.
For the moment you could make a library call to do the same thing.  Not
that 'Forbid()' is a resource that only 1 process can hold at a time, by
definition.

	int
	hog_processor()
	{
	    static char forbidden = 0;

	    Forbid();		/* set forbid, protect 'forbidden' */
	    if (forbidden) {
		Permit();	/* 1 Forbid() is enough   */
		return(1);	/* state was true, forbid */
	    } else
		forbidden = 1;	/* Forbid() active */
		return(0);	/* state was false */
	    }
	}

	unhog_processor(val)	/* re-entrant :-) */
	    int val;
	{
	    if (val)
		return;
	    Permit();
	}
/*    Jim Hutchison   		{dcdwest,ucbvax}!ucsd!celerity!hutch  */
/*    Disclaimor:  I am not an official spokesman for FPS computing   */