Microthreads without Stackless?

[Michael Sparks]

Patrick Maupin wrote:

> In other words, to
> me, the whole point of using coroutines is to make reasoning about the
> system easier (of which reducing code is sometimes a large part). (So
> color me un-academic :)

Assuming a language has stackful coroutines, can you *guarantee* for me that
in the following the filehandle is always closed? (Assume that processFile
is called from inside the start point for a co-routine, and that function
reference process passed through is where the co-routine switching occurs.

def processFile(filename, process):
   try:
      f = open(filename)
      try:
         for i in f:
            process(i)
         f.close()
      except:
         f.close()
   except IOError:
      print "Couldn't open file, didn't do anything"

I would argue that you cannot, unless you start placing restrictions on the
coroutines in a way you (and others) haven't detailed. (Such as ensuring
that when you throw something like exceptions.SystemExit that it propogates
through all the co-routines and hits all the bare except clauses and isn't
stopped by any single one of them.)

The correctness of the code above is predicated on the assumption that
all the calls it makes to other functions will resume immediately. With
stackful coroutines you cannot guarantee this, and as a result reasoning
accurately about code like this is near to impossible in the general case. 

Any implementation of coroutines or co-routine type behaviour has to take
this sort of case into account IMO - or else reasoning about even simple
cases and guaranteering correctness becomes much more difficult. (Consider
"process" being object and "object.process" in the use case above)

Regards,


Michael.