Arthur Bergman <[EMAIL PROTECTED]> wrote: > On 12 Mar 2004, at 19:26, Leopold Toetsch wrote:
>> ... When this stack limit isn't set, stack walking can not be done >> and all PMCs in hardware CPU registers and on the stack are missed, >> which normally leads to ugly DOD bugs - they are really hard to trace >> down. > I think this idea is flawed when it comes to embedding and extending. > Parrot should never walk the stack outside of itself (the embedding > applications stack should be off limit). If you are using Parrot_run_native(), Parrot sets the stack limit to the level at it's run loop. (This was the final solution at the Parrot BOF on Sat at YAPC EU - if you remember :) This is the "stack of itself". But you are missing the point: If the limit is *not* set, Parrot doesn't do any stack walking, which implies *no* walking of hardware CPU registers. > Also note that in this example, there never are any dead objects to > find. So your are sure, that your compiler never puts a local into a CPU register, that in all intermediate function calls the returned PMC is already anchored in the root set? That's just not true. While there are no dead objects, there are unanchored objects, which get happily destroyed, because Parrot doesn't find them to be alive. Your test program and mine are showing that your assumptions are wrong. > I can't do this from embedding space since the internals of interpreter > are not known. >> or better, you run all your code through the wrapper: >> >> - Parrot_run_native() >> which enters a run loop after doing normal initialization (which >> includes setting up a Parrot_exception which is used for exception >> handling. The ops that get run are "enternative <yourcode>" ; end; " > I am sorry, but all I can say is yuck, you can't expect embedders to > have to wrap their main in Parrot. Take it or leave it. Its one function call. Its easy. It does the Right Thing for setting up everything. What's the problem? >> #if 1 >> #include "parrot/parrot.h" >> #endif >> > This is the luxury I cannot do :( You had snipped away my comment, that the extending interface needs some extensions, *if* we finally agree, what are your needs. > In fact, as an embedder, I cannot be sure I always have a local > variable on a stack frame available to me, so I will end up having to > set lo_var_ptr every time I call into the parrot API, hence I suggest > this setting should be in extend.c and embed.c Providing a function call that sets the stack limit ins't the problem. Doing it right is the problem. First you should paint a picture of Ponie's stack layout: Where is the interpreter constructed, where do you call into Parrot ... The range from the stack limit down the call chain to the actual call into Parrot API has to cover all possible auto (stack) Buffer and PMC variables. > Arthur leo
