On Mon, Mar 19, 2001 at 04:49:37PM +0100, Christian Tismer wrote: > A possible bug may be in frame_resume, where you are doing > + f->f_back = tstate->frame; > without taking care of the prior value of f_back. Good catch. There is also a bug when f_suspendvalue is being set (Py_XDECREF should be called first). [Christian on disallowing resume on frame already running] > 1) introduce a lock flag for frames which are currently > executed by some interpreter on the C stack. This is > what Stackless does currently. > Maybe you can just use your new f_suspendvalue field. > frame_resume must check that this value is not NULL > on entry, and set it zero before resuming. Another good catch. It would be easy to set f_stackbottom to NULL at the top of PyEval_EvalFrame. resume already checks this to decide if the frame is resumable. > 2) Do not expose the resume and suspend methods to the > Python user, and recode Generator.py as an extension > module in C. This should prevent abuse of frames. I like the frame methods. However, this may be a good idea since Jython may implement things quite differently. > Proposal for a different interface: > I would change the interface of PyEval_EvalFrame > to accept a return value passed in, like Stackless > has its "passed_retval", and maybe another variable > that explicitly tells the kind of the frame call, > i.e. passing the desired why_code. This also would > make it easier to cope with the other needs of Stackless > later in a cleaner way. > Well, I see you are clearing the f_suspendvalue later. > Maybe just adding the why_code to the parameters > would do. f_suspendvalue can be used for different > things, it can also become the place to store a return > value, or a coroutine transfer parameter. > > In the future, there will not obly be the suspend/resume > interface. Frames will be called for different reasons: > suspend with a value (generators) > return with a value (normal function calls) > transfer with a value (coroutines) > transfer with no value (microthreads) The interface needs some work and I'm happy to change it to better accommodate stackless. f_suspendvalue and f_stackbottom are pretty ugly, IMO. One unexpected benefit: with PyEval_EvalFrame split out of eval_code2 the interpreter is 5% faster on my machine. I suspect the compiler has an easier time optimizing the loop in the smaller function. BTW, where is this stackless light patch I've been hearing about? I would be interested to look at it. Thanks for your comments. Neil
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4