Loosen coroutines restrictions about duktape HOT 2 OPEN

These limitations are certainly a nuisance and should be removed. Removing them is not trivial however. For instance, yielding from the middle of a property read (getter/setter) requires the ability to resume an incomplete property read later with the proper context. Getter/setter calls may also nest, so that a getter call might cause another getter call which then yields - and one needs the ability to resume from that situation.

I'm not yet sure what the best solution approach is: it might be that there's some useful general paradigm to do this (without resorting to actual C stack shuffling which is quite unportable). Another approach is to remove them one by one, with context specific solutions. It's certainly a goal to remove most of these limitations, but I'm not yet sure what the timeframe would be.

from duktape.

Of the restrictions mentioned in the topic, the following are fixed in master (to be 2.2.0):

• A constructor call (new Foo() or Reflect.construct() for Foo)
• Function prototype .call() and .apply()

from duktape.