[32596] in Perl-Users-Digest
Perl-Users Digest, Issue: 3869 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jan 27 03:09:16 2013
Date: Sun, 27 Jan 2013 00:09:03 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 27 Jan 2013 Volume: 11 Number: 3869
Today's topics:
Re: Callback to Perl interpreter in C--something simple <kw@codebykevin.com>
Re: Callback to Perl interpreter in C--something simple <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 26 Jan 2013 07:58:23 -0500
From: Kevin Walzer <kw@codebykevin.com>
Subject: Re: Callback to Perl interpreter in C--something simpler than XS?
Message-Id: <ke0jtf$ln0$1@dont-email.me>
On 1/26/13 5:09 AM, Ben Morrow wrote
>
> ...and now you've gone back to talking about extending perl again. I'm
> confused. How does your program start? Do you want to start in Perl,
> call into C, and then call back into Perl again? That's entirely
> possible, but you have to use both the perlxs and perlcall facilities.
OK, perhaps this is the way I need to go. I'm not embedding Perl; I'm
creating an AppleEvents wrapper that will be loaded into the Perl
interpreter as a package.
>
> However, that C above looks to me as though it's a callback from some
> Apple facility. How does that get invoked? If it gets called
> asynchronously, while there is other Perl code being executed, you will
> probably need to use the ithreads mechanism to prevent the two bits of
> Perl from interfering with each other.
The AppleEvent API is a form of IPC where an app can communicate with
another app via sending AppleEvents. The high-level interface is the
AppleScript language. Something like this:
tell app "Foo"
dosomething()
end tell
My Perl app will be the recipient of the "tell" command in this
instance. My C code is intended to register the Apple Events the app
will handle with the OS, which has to be done in C. But the actual
execution of the code has to be done at the Perl level by the running
interpreter. Does this make sense?
Tcl's C API allows for easy two-way communication between the running
interpreter and code at the C level, and it can be done so without
threads. Here's some similar code in Tcl's C API:
char *data = ckalloc(size + 1);
theErr = AEGetParamPtr(event, keyDirectObject, typeUTF8Text, NULL, data,
size, NULL);
if (theErr == noErr) {
tclErr = Tcl_EvalEx(interp, data, size, TCL_EVAL_GLOBAL);
}
if (tclErr >= 0) {
int reslen;
const char *result =
Tcl_GetStringFromObj(Tcl_GetObjResult(interp), &reslen);
if (tclErr == TCL_OK) {
AEPutParamPtr(reply, keyDirectObject, typeChar, result, reslen);
} else {
AEPutParamPtr(reply, keyErrorString, typeChar, result, reslen);
AEPutParamPtr(reply, keyErrorNumber, typeSInt32, (Ptr) &tclErr,
sizeof(int));
}
The TclEvalEx() call executes the Tcl script, and the output is obtained
at the C level by the Tcl_GetStringFromObj(Tcl_GetObjResult(interp),
&reslen) call, and then passed back along the AppleEvents mechanism
(AEPutParamPtr).
It seems that Perl has two separate API's for interacting with C, rather
than one.
I'll dig deeper into the XS API and see if I can make that dance the way
I want to. I don't want to start a separate Perl interpreter, but rather
use the main one I have. The callback part is what's leading me in this
direction; otherwise I'd just use SWIG.
Other suggestions, anything I've missed, are appreciated.
Thanks,
Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
------------------------------
Date: Sat, 26 Jan 2013 14:20:12 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Callback to Perl interpreter in C--something simpler than XS?
Message-Id: <s95dt9-juk.ln1@anubis.morrow.me.uk>
Quoth Kevin Walzer <kw@codebykevin.com>:
> On 1/26/13 5:09 AM, Ben Morrow wrote
> >
> > However, that C above looks to me as though it's a callback from some
> > Apple facility. How does that get invoked? If it gets called
> > asynchronously, while there is other Perl code being executed, you will
> > probably need to use the ithreads mechanism to prevent the two bits of
> > Perl from interfering with each other.
>
> The AppleEvent API is a form of IPC where an app can communicate with
> another app via sending AppleEvents. The high-level interface is the
> AppleScript language. Something like this:
>
> tell app "Foo"
> dosomething()
> end tell
>
> My Perl app will be the recipient of the "tell" command in this
> instance. My C code is intended to register the Apple Events the app
> will handle with the OS, which has to be done in C. But the actual
> execution of the code has to be done at the Perl level by the running
> interpreter. Does this make sense?
No, you've still missed a step. At what point does that C function you
posted get called? Are you trying to call it from Perl, or does the OS
call it automatically? If the latter, does this only happen when the
process is sitting in some sort of wait-for-events function you call
from Perl, or does it get called asynchronusly, either in a separate
thread or by hijacking the current thread (like signal delivery)?
> Tcl's C API allows for easy two-way communication between the running
> interpreter and code at the C level, and it can be done so without
> threads. Here's some similar code in Tcl's C API:
<snip>
The Perl API ends up looking very similar to that, but you have to be
careful about reentrancy. If your API calls might end up being
asynchronous wrt other API calls made by the main Perl program, you need
to make them against a separate interpreter.
> It seems that Perl has two separate API's for interacting with C, rather
> than one.
No, not really, the high-level documentation is just split across three
documents (perlxs, perlembed, perlcall) for convenience. The detailed
documentation for the whole API is in perlapi. XS itself is not part of
the Perl API as such, it's just a preprocessor for generating the boring
bits of boilerplate. It's perfectly possible to write a perl extension
as a plain C file (and there are sometimes good reasons for doing so).
> I'll dig deeper into the XS API and see if I can make that dance the way
> I want to. I don't want to start a separate Perl interpreter, but rather
> use the main one I have. The callback part is what's leading me in this
> direction; otherwise I'd just use SWIG.
I would recommend staying away from SWIG, at least for perl. I've never
seen a SWIG-generated perl extension that was anything other than
painful to use; IMHO it's trying too hard to provide a cross-interpreter
interface, and the various interpreters' APIs aren't really compatible
enough for that to work. A basic XS interface that doesn't do anything
clever is just a matter of going through and listing the functions
involved.
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3869
***************************************
