ajvincent@juno.com wrote:

> In article <cja27m$1d6u$1@digitaldaemon.com>, Burton Radons says...
> 
>>>If it were a language construct would it limit your choices? Basically I'm wondering if everyone might want to do something slightly different and if we had a language construct it would do one thing, and might not be able to do the other things.
>>
>>I think it works nicely as a library function.  What it all comes down to is monitored execution of a bunch of code.  So the core method of Thread would be:
> 
> Hmm.  If I could ask one minor change, it'd be to see that we save the return
> value for errors (or 0 for a clean operation) and use an out parameter for the
> intended return value(s).  This is how Mozilla's XPCOM code works.

I'm not sure what you're talking about; how would this impact the API I presented, exactly?

   /** Run the thread, calling monitor during execution in the current
     * thread.  If monitor ever returns false, terminate execution of
     * the thread and return false.  If the thread terminates on its
     * own, return true.
     */

   bit Thread.monitored_run (bit delegate () monitor);

   /** Execute run in a second thread, calling monitor during execution
     * in the current thread (passing the thread object).  If monitor
     * ever returns false, terminate execution of the thread and return
     * false.  If the thread terminates on its own, return true.
     */

   bit monitored_run (void delegate () run, bit delegate (Thread thread) monitor);

   /** Execute call, throwing TimeLimitError if it takes longer than the
     * specified number of milliseconds.
     */

   void timelimit (uint milliseconds, void delegate () call);

In article <cja55p$1f2a$1@digitaldaemon.com>, Burton Radons says...
>I'm not sure what you're talking about; how would this impact the API I presented, exactly?

Forget it.  It was just a minor nit anyway.  8-)

ajvincent@juno.com wrote:

> In article <cja55p$1f2a$1@digitaldaemon.com>, Burton Radons says...
> 
>>I'm not sure what you're talking about; how would this impact the API I presented, exactly?
> 
> 
> Forget it.  It was just a minor nit anyway.  8-)
> 
> 

It sounds like you meant a return value from the thread, right?  You can have those with this:

    /** Execute run in a second thread, calling monitor during execution
      * in the current thread (passing the thread object).  If monitor
      * ever returns false, terminate execution of the thread and return
      * false.  If the thread terminates on its own, put the result of
      * run in result and return true.
      */
    template monitored_run_return (ReturnType)
    {
        bit monitored_run_return (
            ReturnType delegate () run,
            bit delegate (Thread thread) monitor,
            out ReturnType result)
        {
            return !monitored_run (delegate void () { result = run (); }, &monitor);
        }
    }

    /* Example usage. */
    void foo ()
    {
        int return_value;

        if (monitored_run_return! (int) (
            delegate int () { return xyz; },
            bit delegate () { return wst; },
            return_value))
        {
            printf ("Got back %d!\n", return_value);
        }
    }

In article <cja6j1$1fv5$1@digitaldaemon.com>, Burton Radons says...

>It sounds like you meant a return value from the thread, right?  You can
>have those with this:
>...
>     /* Example usage. */
>     void foo ()
>     {
>         int return_value;
>
>         if (monitored_run_return! (int) (
>             delegate int () { return xyz; },
>             bit delegate () { return wst; },
>             return_value))
>         {
>             printf ("Got back %d!\n", return_value);
>         }
>     }

That sounds about right.  The only difference I see is that foo() I would think
would be "int foo()", and as a function return 0 for a successful operation.

In other words, just as int main() returns 0 for an error-free operation, I
would think this sort of thing could (not "must"!) do the same.

All I'm saying is that if foo() returns a value, then the encapsulating code
should probably return the same value.  Propagate whatever returns (whether they
be arguments or actual return statements) out from foo() to the main
application.

Sean Kelly wrote:
> In article <cj9bcm$109b$1@digitaldaemon.com>, Sjoerd van Leent says...
> 
>>Chr. Grade wrote:
>>
>>>How about this:
>>>
>>>[1] new loop construct
>>>
>>>whilst
>>>{
>>>  // never loops more times than u32_max or u64_max
>>>  // compiler issues error if looped more times during unit testing
>>>}
>>>
>>>
>>>[2] new prefix for keywords
>>>
>>>no_overflow ubyte nFoo = 0xFF;
>>>
>>>while( nFoo++ ) {};   // error during unit testing
>>>
>>
>>Don't quite see it:
>>
>>invariant {
>>	assert(nFoo <= 0xFF);
>>}
>>
>>it's valid.
>>
>>Wrap a class that uses this for no_overflow...
> 
> 
> But won't ubyte always be <= 0xFF?
> 
> Sean
> 
> 

while( nFoo )
{
  if( isCarryFlag( nFoo ) )
    fnWheep( ... );

  nFoo++;
}