On Wed, Mar 17, 2010 at 9:49 AM, Peter Lobsinger <[email protected]> wrote: > Are you saying that this is both a supported and recommended way of > calling into Parrot? For a subsystem that seems to get refactored > frequently, I *really* don't want to break encapsulation. > > The lack of docs makes me wary. For example, looking at the output of > "perldoc callcontext.pmc" is not very helpful, you have to RTFS to > figure out that you can use push_{string,integer,float,pmc} to build > up a CallContext PMC. Also, I'd like this technique to show up in some > tests, examples, and/or extending/embedding doc. (Yes, I know I've > just volunteered, it's been added to the queue) > > If this method covers everything, why do we expose functions to do the > same thing? Is this just vestigial code? I especially dislike the > functions with misleading names like "sig_object" when we really have > a CallContext.
I'm not sure what the recommendation is. I can tell you that it is supported. Parrot_pcc_invoke_from_sig_object is the core calling routine in the PCC system, and I can't imagine it's going away or going to be changed any time soon. It's taken us quite a long time to get it working the way we want it now. That said, while I say it's possible, it might not be the recommendation. Instead, it may be recommended to call Parrot_ext_call with a signature of "Pc->Pc" (where "c" is a planned-but-not-yet-implemented signature modifier to specify that this is the CallSignature object) and a CallContext PMC as an argument. This technique is definitely being wanted in PIR code, and having it available from C maintains nice symmetry. Which of these two methods is the recommendation is a matter probably left to Allison, though I don't see a problem with using either. Of course, we may want to keep our embedding interface short and simple, and avoid exposing internal-only functions there. As to the lack of docs, that problem is hardly specific to PCC and CallContext. As a bit of an excuse I will note that, as you've pointed out, this system has seen a lot of refactoring recently. I think we're getting to a good stable point where big things won't be changing as much and we can start focusing effort on improving the documentation and known best practices. The docs should improve, and I'll see if I can work on that too. Parrot_ext_call and Parrot_pcc_invoke_from_sig_object don't exactly do the same things. Parrot_ext_call is specifically designed to work from C and take arguments as C datatypes. Plus, it gives us a convenient place to add context entry and exit code, thread synchronization code, or GC management code (turn off GC, such as a concurrent GC, when we exit managed code), etc. I don't think we do any of these things yet, but I can imagine many reasons why we will want to. --Andrew Whitworth > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
