[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Interpreter Locks



If you make it so that this kind of call stack is possible: SC->C->SC
then you ARE making a big change to the SC runtime. In early versions
of SC2 this kind of thing was possible and it was a rat hole which I
had to eliminate or make the whole system unstable for reasons that
are hard to explain in documentation. So you won't be writing
something in the documentation to the effect of "this won't work so
don't try it". You will rethink your design.

I suppose things might get messy if a situation: SC->C->SC->C->SC->C- >SC... occurs where you would have to keep separate stacks for each call and back propagate errors...but I don't see how such a scheme would inherently make the system unstable if handled properly. Then again SC's runtime is pretty complicated and I certainly don't understand all of it.

Possible solution:
I can detect when an attempt is made to call back on SC by setting a global var. when the initial C primitive is called. If this variable is set when calling SC an error will be posted. If a user sees such an error they will have to use a different calling syntax which will defer the message. The invocation will be stored in another global var. so that the return value can be retrieved using another primitive. Doing a call back for async. calling can be done in several ways (which I won't go into).

This would have the effect of allowing normal calling conventions most of the time and the "get the return value later" convention some of the time.