Commit | Line | Data |
---|---|---|
a0d0e21e LW |
1 | =head1 NAME |
2 | ||
3 | perlcall - Perl calling conventions from C | |
4 | ||
5 | =head1 DESCRIPTION | |
6 | ||
d1b91892 | 7 | The purpose of this document is to show you how to call Perl subroutines |
5f05dabc | 8 | directly from C, i.e., how to write I<callbacks>. |
a0d0e21e | 9 | |
d1b91892 AD |
10 | Apart from discussing the C interface provided by Perl for writing |
11 | callbacks the document uses a series of examples to show how the | |
12 | interface actually works in practice. In addition some techniques for | |
13 | coding callbacks are covered. | |
a0d0e21e | 14 | |
d1b91892 | 15 | Examples where callbacks are necessary include |
a0d0e21e LW |
16 | |
17 | =over 5 | |
18 | ||
d1b91892 | 19 | =item * An Error Handler |
a0d0e21e LW |
20 | |
21 | You have created an XSUB interface to an application's C API. | |
22 | ||
23 | A fairly common feature in applications is to allow you to define a C | |
d1b91892 AD |
24 | function that will be called whenever something nasty occurs. What we |
25 | would like is to be able to specify a Perl subroutine that will be | |
26 | called instead. | |
a0d0e21e | 27 | |
95e84303 | 28 | =item * An Event-Driven Program |
a0d0e21e | 29 | |
d1b91892 | 30 | The classic example of where callbacks are used is when writing an |
b0b54b5e | 31 | event driven program, such as for an X11 application. In this case |
184e9718 | 32 | you register functions to be called whenever specific events occur, |
5f05dabc | 33 | e.g., a mouse button is pressed, the cursor moves into a window or a |
d1b91892 | 34 | menu item is selected. |
a0d0e21e LW |
35 | |
36 | =back | |
37 | ||
d1b91892 AD |
38 | Although the techniques described here are applicable when embedding |
39 | Perl in a C program, this is not the primary goal of this document. | |
40 | There are other details that must be considered and are specific to | |
41 | embedding Perl. For details on embedding Perl in C refer to | |
42 | L<perlembed>. | |
a0d0e21e | 43 | |
d1b91892 | 44 | Before you launch yourself head first into the rest of this document, |
02f6dca1 FC |
45 | it would be a good idea to have read the following two documents--L<perlxs> |
46 | and L<perlguts>. | |
a0d0e21e | 47 | |
4929bf7b | 48 | =head1 THE CALL_ FUNCTIONS |
a0d0e21e | 49 | |
d1b91892 AD |
50 | Although this stuff is easier to explain using examples, you first need |
51 | be aware of a few important definitions. | |
a0d0e21e | 52 | |
d1b91892 AD |
53 | Perl has a number of C functions that allow you to call Perl |
54 | subroutines. They are | |
a0d0e21e | 55 | |
4358a253 SS |
56 | I32 call_sv(SV* sv, I32 flags); |
57 | I32 call_pv(char *subname, I32 flags); | |
58 | I32 call_method(char *methname, I32 flags); | |
5aaab254 | 59 | I32 call_argv(char *subname, I32 flags, char **argv); |
a0d0e21e | 60 | |
4929bf7b | 61 | The key function is I<call_sv>. All the other functions are |
d1b91892 | 62 | fairly simple wrappers which make it easier to call Perl subroutines in |
4929bf7b | 63 | special cases. At the end of the day they will all call I<call_sv> |
5f05dabc | 64 | to invoke the Perl subroutine. |
d1b91892 | 65 | |
4929bf7b | 66 | All the I<call_*> functions have a C<flags> parameter which is |
d1b91892 AD |
67 | used to pass a bit mask of options to Perl. This bit mask operates |
68 | identically for each of the functions. The settings available in the | |
d0554719 | 69 | bit mask are discussed in L</FLAG VALUES>. |
d1b91892 AD |
70 | |
71 | Each of the functions will now be discussed in turn. | |
72 | ||
73 | =over 5 | |
74 | ||
4929bf7b | 75 | =item call_sv |
d1b91892 | 76 | |
02f6dca1 | 77 | I<call_sv> takes two parameters. The first, C<sv>, is an SV*. |
d1b91892 AD |
78 | This allows you to specify the Perl subroutine to be called either as a |
79 | C string (which has first been converted to an SV) or a reference to a | |
d0554719 | 80 | subroutine. The section, L</Using call_sv>, shows how you can make |
4929bf7b | 81 | use of I<call_sv>. |
d1b91892 | 82 | |
4929bf7b | 83 | =item call_pv |
d1b91892 | 84 | |
4929bf7b | 85 | The function, I<call_pv>, is similar to I<call_sv> except it |
d1b91892 | 86 | expects its first parameter to be a C char* which identifies the Perl |
4929bf7b | 87 | subroutine you want to call, e.g., C<call_pv("fred", 0)>. If the |
d1b91892 | 88 | subroutine you want to call is in another package, just include the |
5f05dabc | 89 | package name in the string, e.g., C<"pkg::fred">. |
d1b91892 | 90 | |
4929bf7b | 91 | =item call_method |
d1b91892 | 92 | |
4929bf7b | 93 | The function I<call_method> is used to call a method from a Perl |
d1b91892 AD |
94 | class. The parameter C<methname> corresponds to the name of the method |
95 | to be called. Note that the class that the method belongs to is passed | |
96 | on the Perl stack rather than in the parameter list. This class can be | |
97 | either the name of the class (for a static method) or a reference to an | |
98 | object (for a virtual method). See L<perlobj> for more information on | |
d0554719 | 99 | static and virtual methods and L</Using call_method> for an example |
4929bf7b | 100 | of using I<call_method>. |
d1b91892 | 101 | |
4929bf7b | 102 | =item call_argv |
d1b91892 | 103 | |
4929bf7b | 104 | I<call_argv> calls the Perl subroutine specified by the C string |
d1b91892 | 105 | stored in the C<subname> parameter. It also takes the usual C<flags> |
02f6dca1 | 106 | parameter. The final parameter, C<argv>, consists of a NULL-terminated |
d1b91892 | 107 | list of C strings to be passed as parameters to the Perl subroutine. |
d0554719 | 108 | See L</Using call_argv>. |
d1b91892 AD |
109 | |
110 | =back | |
111 | ||
112 | All the functions return an integer. This is a count of the number of | |
113 | items returned by the Perl subroutine. The actual items returned by the | |
114 | subroutine are stored on the Perl stack. | |
115 | ||
116 | As a general rule you should I<always> check the return value from | |
117 | these functions. Even if you are expecting only a particular number of | |
118 | values to be returned from the Perl subroutine, there is nothing to | |
19799a22 | 119 | stop someone from doing something unexpected--don't say you haven't |
d1b91892 AD |
120 | been warned. |
121 | ||
122 | =head1 FLAG VALUES | |
123 | ||
87b26de2 | 124 | The C<flags> parameter in all the I<call_*> functions is one of C<G_VOID>, |
eb7e169e | 125 | C<G_SCALAR>, or C<G_LIST>, which indicate the call context, OR'ed together |
0b06a753 | 126 | with a bit mask of any combination of the other G_* symbols defined below. |
d1b91892 | 127 | |
54310121 | 128 | =head2 G_VOID |
129 | ||
52ae2233 KW |
130 | =for apidoc AmnUh||G_VOID |
131 | ||
54310121 | 132 | Calls the Perl subroutine in a void context. |
133 | ||
134 | This flag has 2 effects: | |
135 | ||
136 | =over 5 | |
137 | ||
138 | =item 1. | |
139 | ||
140 | It indicates to the subroutine being called that it is executing in | |
141 | a void context (if it executes I<wantarray> the result will be the | |
142 | undefined value). | |
143 | ||
144 | =item 2. | |
145 | ||
146 | It ensures that nothing is actually returned from the subroutine. | |
147 | ||
148 | =back | |
149 | ||
4929bf7b | 150 | The value returned by the I<call_*> function indicates how many |
02f6dca1 | 151 | items have been returned by the Perl subroutine--in this case it will |
54310121 | 152 | be 0. |
153 | ||
154 | ||
d1b91892 AD |
155 | =head2 G_SCALAR |
156 | ||
52ae2233 KW |
157 | =for apidoc AmnUh||G_SCALAR |
158 | ||
d1b91892 | 159 | Calls the Perl subroutine in a scalar context. This is the default |
4929bf7b | 160 | context flag setting for all the I<call_*> functions. |
d1b91892 | 161 | |
184e9718 | 162 | This flag has 2 effects: |
d1b91892 AD |
163 | |
164 | =over 5 | |
165 | ||
166 | =item 1. | |
167 | ||
184e9718 | 168 | It indicates to the subroutine being called that it is executing in a |
d1b91892 | 169 | scalar context (if it executes I<wantarray> the result will be false). |
a0d0e21e | 170 | |
d1b91892 AD |
171 | =item 2. |
172 | ||
184e9718 | 173 | It ensures that only a scalar is actually returned from the subroutine. |
d1b91892 AD |
174 | The subroutine can, of course, ignore the I<wantarray> and return a |
175 | list anyway. If so, then only the last element of the list will be | |
176 | returned. | |
177 | ||
178 | =back | |
179 | ||
4929bf7b | 180 | The value returned by the I<call_*> function indicates how many |
d1b91892 AD |
181 | items have been returned by the Perl subroutine - in this case it will |
182 | be either 0 or 1. | |
a0d0e21e | 183 | |
d1b91892 | 184 | If 0, then you have specified the G_DISCARD flag. |
a0d0e21e | 185 | |
d1b91892 | 186 | If 1, then the item actually returned by the Perl subroutine will be |
d0554719 | 187 | stored on the Perl stack - the section L</Returning a Scalar> shows how |
d1b91892 AD |
188 | to access this value on the stack. Remember that regardless of how |
189 | many items the Perl subroutine returns, only the last one will be | |
190 | accessible from the stack - think of the case where only one value is | |
191 | returned as being a list with only one element. Any other items that | |
192 | were returned will not exist by the time control returns from the | |
d0554719 TC |
193 | I<call_*> function. The section L</Returning a List in Scalar |
194 | Context> shows an example of this behavior. | |
a0d0e21e | 195 | |
a0d0e21e | 196 | |
eb7e169e | 197 | =head2 G_LIST |
a0d0e21e | 198 | |
eb7e169e | 199 | =for apidoc AmnUh||G_LIST |
52ae2233 | 200 | |
eb7e169e PE |
201 | Calls the Perl subroutine in a list context. Prior to Perl version |
202 | 5.35.1 this was called C<G_ARRAY>. | |
a0d0e21e | 203 | |
184e9718 | 204 | As with G_SCALAR, this flag has 2 effects: |
a0d0e21e LW |
205 | |
206 | =over 5 | |
207 | ||
d1b91892 AD |
208 | =item 1. |
209 | ||
90fdbbb7 DC |
210 | It indicates to the subroutine being called that it is executing in a |
211 | list context (if it executes I<wantarray> the result will be true). | |
a0d0e21e | 212 | |
d1b91892 | 213 | =item 2. |
a0d0e21e | 214 | |
184e9718 | 215 | It ensures that all items returned from the subroutine will be |
4929bf7b | 216 | accessible when control returns from the I<call_*> function. |
a0d0e21e | 217 | |
d1b91892 | 218 | =back |
a0d0e21e | 219 | |
4929bf7b | 220 | The value returned by the I<call_*> function indicates how many |
d1b91892 | 221 | items have been returned by the Perl subroutine. |
a0d0e21e | 222 | |
184e9718 | 223 | If 0, then you have specified the G_DISCARD flag. |
a0d0e21e | 224 | |
d1b91892 AD |
225 | If not 0, then it will be a count of the number of items returned by |
226 | the subroutine. These items will be stored on the Perl stack. The | |
d0554719 | 227 | section L</Returning a List of Values> gives an example of using the |
eb7e169e | 228 | G_LIST flag and the mechanics of accessing the returned items from the |
d1b91892 | 229 | Perl stack. |
a0d0e21e | 230 | |
d1b91892 | 231 | =head2 G_DISCARD |
a0d0e21e | 232 | |
52ae2233 KW |
233 | =for apidoc AmnUh||G_DISCARD |
234 | ||
4929bf7b | 235 | By default, the I<call_*> functions place the items returned from |
d1b91892 AD |
236 | by the Perl subroutine on the stack. If you are not interested in |
237 | these items, then setting this flag will make Perl get rid of them | |
238 | automatically for you. Note that it is still possible to indicate a | |
eb7e169e | 239 | context to the Perl subroutine by using either G_SCALAR or G_LIST. |
a0d0e21e | 240 | |
d1b91892 | 241 | If you do not set this flag then it is I<very> important that you make |
5f05dabc | 242 | sure that any temporaries (i.e., parameters passed to the Perl |
d1b91892 | 243 | subroutine and values returned from the subroutine) are disposed of |
d0554719 TC |
244 | yourself. The section L</Returning a Scalar> gives details of how to |
245 | dispose of these temporaries explicitly and the section L</Using Perl to | |
246 | Dispose of Temporaries> discusses the specific circumstances where you | |
d1b91892 | 247 | can ignore the problem and let Perl deal with it for you. |
a0d0e21e | 248 | |
d1b91892 | 249 | =head2 G_NOARGS |
a0d0e21e | 250 | |
52ae2233 KW |
251 | =for apidoc AmnUh||G_NOARGS |
252 | ||
4929bf7b | 253 | Whenever a Perl subroutine is called using one of the I<call_*> |
d1b91892 AD |
254 | functions, it is assumed by default that parameters are to be passed to |
255 | the subroutine. If you are not passing any parameters to the Perl | |
256 | subroutine, you can save a bit of time by setting this flag. It has | |
257 | the effect of not creating the C<@_> array for the Perl subroutine. | |
a0d0e21e | 258 | |
d1b91892 AD |
259 | Although the functionality provided by this flag may seem |
260 | straightforward, it should be used only if there is a good reason to do | |
02f6dca1 | 261 | so. The reason for being cautious is that, even if you have specified |
d1b91892 AD |
262 | the G_NOARGS flag, it is still possible for the Perl subroutine that |
263 | has been called to think that you have passed it parameters. | |
a0d0e21e | 264 | |
d1b91892 AD |
265 | In fact, what can happen is that the Perl subroutine you have called |
266 | can access the C<@_> array from a previous Perl subroutine. This will | |
4929bf7b | 267 | occur when the code that is executing the I<call_*> function has |
d1b91892 AD |
268 | itself been called from another Perl subroutine. The code below |
269 | illustrates this | |
a0d0e21e | 270 | |
84f709e7 JH |
271 | sub fred |
272 | { print "@_\n" } | |
a0d0e21e | 273 | |
84f709e7 JH |
274 | sub joe |
275 | { &fred } | |
a0d0e21e | 276 | |
4358a253 | 277 | &joe(1,2,3); |
a0d0e21e LW |
278 | |
279 | This will print | |
280 | ||
d1b91892 AD |
281 | 1 2 3 |
282 | ||
283 | What has happened is that C<fred> accesses the C<@_> array which | |
284 | belongs to C<joe>. | |
a0d0e21e | 285 | |
a0d0e21e | 286 | |
54310121 | 287 | =head2 G_EVAL |
a0d0e21e | 288 | |
52ae2233 KW |
289 | =for apidoc AmnUh||G_EVAL |
290 | ||
d1b91892 | 291 | It is possible for the Perl subroutine you are calling to terminate |
5f05dabc | 292 | abnormally, e.g., by calling I<die> explicitly or by not actually |
268118b2 HS |
293 | existing. By default, when either of these events occurs, the |
294 | process will terminate immediately. If you want to trap this | |
d1b91892 AD |
295 | type of event, specify the G_EVAL flag. It will put an I<eval { }> |
296 | around the subroutine call. | |
a0d0e21e | 297 | |
4929bf7b | 298 | Whenever control returns from the I<call_*> function you need to |
d1b91892 AD |
299 | check the C<$@> variable as you would in a normal Perl script. |
300 | ||
4929bf7b | 301 | The value returned from the I<call_*> function is dependent on |
d1b91892 | 302 | what other flags have been specified and whether an error has |
184e9718 | 303 | occurred. Here are all the different cases that can occur: |
d1b91892 AD |
304 | |
305 | =over 5 | |
306 | ||
307 | =item * | |
308 | ||
4929bf7b | 309 | If the I<call_*> function returns normally, then the value |
d1b91892 AD |
310 | returned is as specified in the previous sections. |
311 | ||
312 | =item * | |
313 | ||
314 | If G_DISCARD is specified, the return value will always be 0. | |
315 | ||
316 | =item * | |
317 | ||
eb7e169e | 318 | If G_LIST is specified I<and> an error has occurred, the return value |
d1b91892 AD |
319 | will always be 0. |
320 | ||
321 | =item * | |
a0d0e21e | 322 | |
d1b91892 AD |
323 | If G_SCALAR is specified I<and> an error has occurred, the return value |
324 | will be 1 and the value on the top of the stack will be I<undef>. This | |
325 | means that if you have already detected the error by checking C<$@> and | |
326 | you want the program to continue, you must remember to pop the I<undef> | |
327 | from the stack. | |
a0d0e21e LW |
328 | |
329 | =back | |
330 | ||
d0554719 | 331 | See L</Using G_EVAL> for details on using G_EVAL. |
d1b91892 | 332 | |
c07a80fd | 333 | =head2 G_KEEPERR |
334 | ||
52ae2233 KW |
335 | =for apidoc AmnUh||G_KEEPERR |
336 | ||
7ce09284 Z |
337 | Using the G_EVAL flag described above will always set C<$@>: clearing |
338 | it if there was no error, and setting it to describe the error if there | |
339 | was an error in the called code. This is what you want if your intention | |
340 | is to handle possible errors, but sometimes you just want to trap errors | |
341 | and stop them interfering with the rest of the program. | |
342 | ||
343 | This scenario will mostly be applicable to code that is meant to be called | |
344 | from within destructors, asynchronous callbacks, and signal handlers. | |
345 | In such situations, where the code being called has little relation to the | |
346 | surrounding dynamic context, the main program needs to be insulated from | |
347 | errors in the called code, even if they can't be handled intelligently. | |
348 | It may also be useful to do this with code for C<__DIE__> or C<__WARN__> | |
349 | hooks, and C<tie> functions. | |
c07a80fd | 350 | |
351 | The G_KEEPERR flag is meant to be used in conjunction with G_EVAL in | |
be064c4a DM |
352 | I<call_*> functions that are used to implement such code, or with |
353 | C<eval_sv>. This flag has no effect on the C<call_*> functions when | |
354 | G_EVAL is not used. | |
c07a80fd | 355 | |
7ce09284 Z |
356 | When G_KEEPERR is used, any error in the called code will terminate the |
357 | call as usual, and the error will not propagate beyond the call (as usual | |
358 | for G_EVAL), but it will not go into C<$@>. Instead the error will be | |
359 | converted into a warning, prefixed with the string "\t(in cleanup)". | |
360 | This can be disabled using C<no warnings 'misc'>. If there is no error, | |
361 | C<$@> will not be cleared. | |
c07a80fd | 362 | |
be064c4a DM |
363 | Note that the G_KEEPERR flag does not propagate into inner evals; these |
364 | may still set C<$@>. | |
365 | ||
c07a80fd | 366 | The G_KEEPERR flag was introduced in Perl version 5.002. |
367 | ||
d0554719 | 368 | See L</Using G_KEEPERR> for an example of a situation that warrants the |
c07a80fd | 369 | use of this flag. |
370 | ||
54310121 | 371 | =head2 Determining the Context |
d1b91892 AD |
372 | |
373 | As mentioned above, you can determine the context of the currently | |
54310121 | 374 | executing subroutine in Perl with I<wantarray>. The equivalent test |
375 | can be made in C by using the C<GIMME_V> macro, which returns | |
eb7e169e | 376 | C<G_LIST> if you have been called in a list context, C<G_SCALAR> if |
02f6dca1 | 377 | in a scalar context, or C<G_VOID> if in a void context (i.e., the |
54310121 | 378 | return value will not be used). An older version of this macro is |
379 | called C<GIMME>; in a void context it returns C<G_SCALAR> instead of | |
380 | C<G_VOID>. An example of using the C<GIMME_V> macro is shown in | |
d0554719 | 381 | section L</Using GIMME_V>. |
d1b91892 | 382 | |
a0d0e21e LW |
383 | =head1 EXAMPLES |
384 | ||
02f6dca1 | 385 | Enough of the definition talk! Let's have a few examples. |
a0d0e21e | 386 | |
d1b91892 AD |
387 | Perl provides many macros to assist in accessing the Perl stack. |
388 | Wherever possible, these macros should always be used when interfacing | |
5f05dabc | 389 | to Perl internals. We hope this should make the code less vulnerable |
d1b91892 | 390 | to any changes made to Perl in the future. |
a0d0e21e | 391 | |
d1b91892 | 392 | Another point worth noting is that in the first series of examples I |
4929bf7b | 393 | have made use of only the I<call_pv> function. This has been done |
d1b91892 | 394 | to keep the code simpler and ease you into the topic. Wherever |
4929bf7b GS |
395 | possible, if the choice is between using I<call_pv> and |
396 | I<call_sv>, you should always try to use I<call_sv>. See | |
d0554719 | 397 | L</Using call_sv> for details. |
a0d0e21e | 398 | |
02f6dca1 | 399 | =head2 No Parameters, Nothing Returned |
a0d0e21e | 400 | |
d1b91892 AD |
401 | This first trivial example will call a Perl subroutine, I<PrintUID>, to |
402 | print out the UID of the process. | |
a0d0e21e | 403 | |
84f709e7 JH |
404 | sub PrintUID |
405 | { | |
4358a253 | 406 | print "UID is $<\n"; |
a0d0e21e LW |
407 | } |
408 | ||
d1b91892 | 409 | and here is a C function to call it |
a0d0e21e | 410 | |
d1b91892 | 411 | static void |
a0d0e21e LW |
412 | call_PrintUID() |
413 | { | |
4358a253 | 414 | dSP; |
a0d0e21e | 415 | |
4358a253 SS |
416 | PUSHMARK(SP); |
417 | call_pv("PrintUID", G_DISCARD|G_NOARGS); | |
a0d0e21e LW |
418 | } |
419 | ||
02f6dca1 | 420 | Simple, eh? |
a0d0e21e | 421 | |
02f6dca1 | 422 | A few points to note about this example: |
a0d0e21e LW |
423 | |
424 | =over 5 | |
425 | ||
d1b91892 | 426 | =item 1. |
a0d0e21e | 427 | |
924508f0 | 428 | Ignore C<dSP> and C<PUSHMARK(SP)> for now. They will be discussed in |
d1b91892 | 429 | the next example. |
a0d0e21e LW |
430 | |
431 | =item 2. | |
432 | ||
d1b91892 AD |
433 | We aren't passing any parameters to I<PrintUID> so G_NOARGS can be |
434 | specified. | |
a0d0e21e | 435 | |
d1b91892 | 436 | =item 3. |
a0d0e21e LW |
437 | |
438 | We aren't interested in anything returned from I<PrintUID>, so | |
5f05dabc | 439 | G_DISCARD is specified. Even if I<PrintUID> was changed to |
a0d0e21e | 440 | return some value(s), having specified G_DISCARD will mean that they |
4929bf7b | 441 | will be wiped by the time control returns from I<call_pv>. |
a0d0e21e | 442 | |
d1b91892 | 443 | =item 4. |
a0d0e21e | 444 | |
4929bf7b | 445 | As I<call_pv> is being used, the Perl subroutine is specified as a |
d1b91892 AD |
446 | C string. In this case the subroutine name has been 'hard-wired' into the |
447 | code. | |
a0d0e21e LW |
448 | |
449 | =item 5. | |
450 | ||
d1b91892 | 451 | Because we specified G_DISCARD, it is not necessary to check the value |
4929bf7b | 452 | returned from I<call_pv>. It will always be 0. |
a0d0e21e LW |
453 | |
454 | =back | |
455 | ||
d1b91892 | 456 | =head2 Passing Parameters |
a0d0e21e | 457 | |
d1b91892 | 458 | Now let's make a slightly more complex example. This time we want to |
19799a22 GS |
459 | call a Perl subroutine, C<LeftString>, which will take 2 parameters--a |
460 | string ($s) and an integer ($n). The subroutine will simply | |
461 | print the first $n characters of the string. | |
a0d0e21e | 462 | |
02f6dca1 | 463 | So the Perl subroutine would look like this: |
a0d0e21e | 464 | |
84f709e7 JH |
465 | sub LeftString |
466 | { | |
4358a253 SS |
467 | my($s, $n) = @_; |
468 | print substr($s, 0, $n), "\n"; | |
a0d0e21e LW |
469 | } |
470 | ||
02f6dca1 | 471 | The C function required to call I<LeftString> would look like this: |
a0d0e21e LW |
472 | |
473 | static void | |
474 | call_LeftString(a, b) | |
4358a253 SS |
475 | char * a; |
476 | int b; | |
a0d0e21e | 477 | { |
4358a253 | 478 | dSP; |
a0d0e21e | 479 | |
4358a253 SS |
480 | ENTER; |
481 | SAVETMPS; | |
9b6570b4 | 482 | |
4358a253 | 483 | PUSHMARK(SP); |
d0554719 TC |
484 | EXTEND(SP, 2); |
485 | PUSHs(sv_2mortal(newSVpv(a, 0))); | |
486 | PUSHs(sv_2mortal(newSViv(b))); | |
4358a253 | 487 | PUTBACK; |
a0d0e21e | 488 | |
4929bf7b | 489 | call_pv("LeftString", G_DISCARD); |
9b6570b4 | 490 | |
4358a253 SS |
491 | FREETMPS; |
492 | LEAVE; | |
a0d0e21e LW |
493 | } |
494 | ||
a0d0e21e LW |
495 | Here are a few notes on the C function I<call_LeftString>. |
496 | ||
497 | =over 5 | |
498 | ||
d1b91892 | 499 | =item 1. |
a0d0e21e | 500 | |
d1b91892 AD |
501 | Parameters are passed to the Perl subroutine using the Perl stack. |
502 | This is the purpose of the code beginning with the line C<dSP> and | |
1e62ac33 | 503 | ending with the line C<PUTBACK>. The C<dSP> declares a local copy |
924508f0 GS |
504 | of the stack pointer. This local copy should B<always> be accessed |
505 | as C<SP>. | |
a0d0e21e | 506 | |
d1b91892 | 507 | =item 2. |
a0d0e21e LW |
508 | |
509 | If you are going to put something onto the Perl stack, you need to know | |
19799a22 | 510 | where to put it. This is the purpose of the macro C<dSP>--it declares |
d1b91892 | 511 | and initializes a I<local> copy of the Perl stack pointer. |
a0d0e21e LW |
512 | |
513 | All the other macros which will be used in this example require you to | |
d1b91892 | 514 | have used this macro. |
a0d0e21e | 515 | |
d1b91892 AD |
516 | The exception to this rule is if you are calling a Perl subroutine |
517 | directly from an XSUB function. In this case it is not necessary to | |
19799a22 | 518 | use the C<dSP> macro explicitly--it will be declared for you |
d1b91892 | 519 | automatically. |
a0d0e21e | 520 | |
d1b91892 | 521 | =item 3. |
a0d0e21e LW |
522 | |
523 | Any parameters to be pushed onto the stack should be bracketed by the | |
d1b91892 | 524 | C<PUSHMARK> and C<PUTBACK> macros. The purpose of these two macros, in |
5f05dabc | 525 | this context, is to count the number of parameters you are |
526 | pushing automatically. Then whenever Perl is creating the C<@_> array for the | |
d1b91892 AD |
527 | subroutine, it knows how big to make it. |
528 | ||
529 | The C<PUSHMARK> macro tells Perl to make a mental note of the current | |
530 | stack pointer. Even if you aren't passing any parameters (like the | |
d0554719 | 531 | example shown in the section L</No Parameters, Nothing Returned>) you |
d1b91892 | 532 | must still call the C<PUSHMARK> macro before you can call any of the |
4929bf7b | 533 | I<call_*> functions--Perl still needs to know that there are no |
d1b91892 AD |
534 | parameters. |
535 | ||
536 | The C<PUTBACK> macro sets the global copy of the stack pointer to be | |
02f6dca1 | 537 | the same as our local copy. If we didn't do this, I<call_pv> |
19799a22 | 538 | wouldn't know where the two parameters we pushed were--remember that |
d1b91892 AD |
539 | up to now all the stack pointer manipulation we have done is with our |
540 | local copy, I<not> the global copy. | |
541 | ||
542 | =item 4. | |
543 | ||
d0554719 TC |
544 | Next, we come to EXTEND and PUSHs. This is where the parameters |
545 | actually get pushed onto the stack. In this case we are pushing a | |
546 | string and an integer. | |
547 | ||
548 | Alternatively you can use the XPUSHs() macro, which combines a | |
549 | C<EXTEND(SP, 1)> and C<PUSHs()>. This is less efficient if you're | |
550 | pushing multiple values. | |
a0d0e21e | 551 | |
54310121 | 552 | See L<perlguts/"XSUBs and the Argument Stack"> for details |
d0554719 | 553 | on how the PUSH macros work. |
a0d0e21e | 554 | |
087fe227 | 555 | =item 5. |
a0d0e21e | 556 | |
9b6570b4 AB |
557 | Because we created temporary values (by means of sv_2mortal() calls) |
558 | we will have to tidy up the Perl stack and dispose of mortal SVs. | |
559 | ||
560 | This is the purpose of | |
561 | ||
4358a253 SS |
562 | ENTER; |
563 | SAVETMPS; | |
9b6570b4 AB |
564 | |
565 | at the start of the function, and | |
566 | ||
4358a253 SS |
567 | FREETMPS; |
568 | LEAVE; | |
9b6570b4 AB |
569 | |
570 | at the end. The C<ENTER>/C<SAVETMPS> pair creates a boundary for any | |
571 | temporaries we create. This means that the temporaries we get rid of | |
572 | will be limited to those which were created after these calls. | |
573 | ||
574 | The C<FREETMPS>/C<LEAVE> pair will get rid of any values returned by | |
575 | the Perl subroutine (see next example), plus it will also dump the | |
576 | mortal SVs we have created. Having C<ENTER>/C<SAVETMPS> at the | |
577 | beginning of the code makes sure that no other mortals are destroyed. | |
578 | ||
02f6dca1 | 579 | Think of these macros as working a bit like C<{> and C<}> in Perl |
9b6570b4 AB |
580 | to limit the scope of local variables. |
581 | ||
d0554719 | 582 | See the section L</Using Perl to Dispose of Temporaries> for details of |
9b6570b4 AB |
583 | an alternative to using these macros. |
584 | ||
087fe227 | 585 | =item 6. |
9b6570b4 | 586 | |
087fe227 JA |
587 | Finally, I<LeftString> can now be called via the I<call_pv> function. |
588 | The only flag specified this time is G_DISCARD. Because we are passing | |
589 | 2 parameters to the Perl subroutine this time, we have not specified | |
590 | G_NOARGS. | |
a0d0e21e LW |
591 | |
592 | =back | |
593 | ||
d1b91892 | 594 | =head2 Returning a Scalar |
a0d0e21e | 595 | |
d1b91892 AD |
596 | Now for an example of dealing with the items returned from a Perl |
597 | subroutine. | |
a0d0e21e | 598 | |
5f05dabc | 599 | Here is a Perl subroutine, I<Adder>, that takes 2 integer parameters |
d1b91892 | 600 | and simply returns their sum. |
a0d0e21e | 601 | |
84f709e7 JH |
602 | sub Adder |
603 | { | |
4358a253 SS |
604 | my($a, $b) = @_; |
605 | $a + $b; | |
a0d0e21e LW |
606 | } |
607 | ||
5f05dabc | 608 | Because we are now concerned with the return value from I<Adder>, the C |
d1b91892 | 609 | function required to call it is now a bit more complex. |
a0d0e21e LW |
610 | |
611 | static void | |
612 | call_Adder(a, b) | |
4358a253 SS |
613 | int a; |
614 | int b; | |
a0d0e21e | 615 | { |
4358a253 SS |
616 | dSP; |
617 | int count; | |
a0d0e21e | 618 | |
4358a253 | 619 | ENTER; |
a0d0e21e LW |
620 | SAVETMPS; |
621 | ||
4358a253 | 622 | PUSHMARK(SP); |
d0554719 TC |
623 | EXTEND(SP, 2); |
624 | PUSHs(sv_2mortal(newSViv(a))); | |
625 | PUSHs(sv_2mortal(newSViv(b))); | |
4358a253 | 626 | PUTBACK; |
a0d0e21e | 627 | |
4929bf7b | 628 | count = call_pv("Adder", G_SCALAR); |
a0d0e21e | 629 | |
4358a253 | 630 | SPAGAIN; |
a0d0e21e | 631 | |
d1b91892 | 632 | if (count != 1) |
4358a253 | 633 | croak("Big trouble\n"); |
a0d0e21e | 634 | |
4358a253 | 635 | printf ("The sum of %d and %d is %d\n", a, b, POPi); |
a0d0e21e | 636 | |
4358a253 SS |
637 | PUTBACK; |
638 | FREETMPS; | |
639 | LEAVE; | |
a0d0e21e LW |
640 | } |
641 | ||
a0d0e21e LW |
642 | Points to note this time are |
643 | ||
644 | =over 5 | |
645 | ||
54310121 | 646 | =item 1. |
a0d0e21e | 647 | |
02f6dca1 | 648 | The only flag specified this time was G_SCALAR. That means that the C<@_> |
d1b91892 | 649 | array will be created and that the value returned by I<Adder> will |
4929bf7b | 650 | still exist after the call to I<call_pv>. |
a0d0e21e | 651 | |
a0d0e21e LW |
652 | =item 2. |
653 | ||
a0d0e21e LW |
654 | The purpose of the macro C<SPAGAIN> is to refresh the local copy of the |
655 | stack pointer. This is necessary because it is possible that the memory | |
ed874981 | 656 | allocated to the Perl stack has been reallocated during the |
4929bf7b | 657 | I<call_pv> call. |
a0d0e21e | 658 | |
d1b91892 | 659 | If you are making use of the Perl stack pointer in your code you must |
54310121 | 660 | always refresh the local copy using SPAGAIN whenever you make use |
4929bf7b | 661 | of the I<call_*> functions or any other Perl internal function. |
a0d0e21e | 662 | |
9b6570b4 | 663 | =item 3. |
a0d0e21e | 664 | |
d1b91892 | 665 | Although only a single value was expected to be returned from I<Adder>, |
4929bf7b | 666 | it is still good practice to check the return code from I<call_pv> |
d1b91892 | 667 | anyway. |
a0d0e21e | 668 | |
d1b91892 AD |
669 | Expecting a single value is not quite the same as knowing that there |
670 | will be one. If someone modified I<Adder> to return a list and we | |
671 | didn't check for that possibility and take appropriate action the Perl | |
672 | stack would end up in an inconsistent state. That is something you | |
5f05dabc | 673 | I<really> don't want to happen ever. |
a0d0e21e | 674 | |
9b6570b4 | 675 | =item 4. |
a0d0e21e | 676 | |
d1b91892 AD |
677 | The C<POPi> macro is used here to pop the return value from the stack. |
678 | In this case we wanted an integer, so C<POPi> was used. | |
a0d0e21e LW |
679 | |
680 | ||
d1b91892 AD |
681 | Here is the complete list of POP macros available, along with the types |
682 | they return. | |
a0d0e21e | 683 | |
d1b91892 | 684 | POPs SV |
d0554719 TC |
685 | POPp pointer (PV) |
686 | POPpbytex pointer to bytes (PV) | |
687 | POPn double (NV) | |
688 | POPi integer (IV) | |
689 | POPu unsigned integer (UV) | |
d1b91892 | 690 | POPl long |
d0554719 TC |
691 | POPul unsigned long |
692 | ||
693 | Since these macros have side-effects don't use them as arguments to | |
694 | macros that may evaluate their argument several times, for example: | |
695 | ||
696 | /* Bad idea, don't do this */ | |
697 | STRLEN len; | |
698 | const char *s = SvPV(POPs, len); | |
699 | ||
700 | Instead, use a temporary: | |
701 | ||
702 | STRLEN len; | |
703 | SV *sv = POPs; | |
704 | const char *s = SvPV(sv, len); | |
705 | ||
706 | or a macro that guarantees it will evaluate its arguments only once: | |
707 | ||
708 | STRLEN len; | |
709 | const char *s = SvPVx(POPs, len); | |
a0d0e21e | 710 | |
9b6570b4 | 711 | =item 5. |
a0d0e21e | 712 | |
d1b91892 AD |
713 | The final C<PUTBACK> is used to leave the Perl stack in a consistent |
714 | state before exiting the function. This is necessary because when we | |
715 | popped the return value from the stack with C<POPi> it updated only our | |
716 | local copy of the stack pointer. Remember, C<PUTBACK> sets the global | |
717 | stack pointer to be the same as our local copy. | |
a0d0e21e LW |
718 | |
719 | =back | |
720 | ||
721 | ||
02f6dca1 | 722 | =head2 Returning a List of Values |
a0d0e21e | 723 | |
d1b91892 AD |
724 | Now, let's extend the previous example to return both the sum of the |
725 | parameters and the difference. | |
a0d0e21e | 726 | |
d1b91892 | 727 | Here is the Perl subroutine |
a0d0e21e | 728 | |
84f709e7 JH |
729 | sub AddSubtract |
730 | { | |
4358a253 SS |
731 | my($a, $b) = @_; |
732 | ($a+$b, $a-$b); | |
a0d0e21e LW |
733 | } |
734 | ||
a0d0e21e LW |
735 | and this is the C function |
736 | ||
737 | static void | |
738 | call_AddSubtract(a, b) | |
4358a253 SS |
739 | int a; |
740 | int b; | |
a0d0e21e | 741 | { |
4358a253 SS |
742 | dSP; |
743 | int count; | |
a0d0e21e | 744 | |
4358a253 | 745 | ENTER; |
a0d0e21e LW |
746 | SAVETMPS; |
747 | ||
4358a253 | 748 | PUSHMARK(SP); |
d0554719 TC |
749 | EXTEND(SP, 2); |
750 | PUSHs(sv_2mortal(newSViv(a))); | |
751 | PUSHs(sv_2mortal(newSViv(b))); | |
4358a253 | 752 | PUTBACK; |
a0d0e21e | 753 | |
eb7e169e | 754 | count = call_pv("AddSubtract", G_LIST); |
a0d0e21e | 755 | |
4358a253 | 756 | SPAGAIN; |
a0d0e21e | 757 | |
d1b91892 | 758 | if (count != 2) |
4358a253 | 759 | croak("Big trouble\n"); |
a0d0e21e | 760 | |
4358a253 SS |
761 | printf ("%d - %d = %d\n", a, b, POPi); |
762 | printf ("%d + %d = %d\n", a, b, POPi); | |
a0d0e21e | 763 | |
4358a253 SS |
764 | PUTBACK; |
765 | FREETMPS; | |
766 | LEAVE; | |
a0d0e21e LW |
767 | } |
768 | ||
d1b91892 AD |
769 | If I<call_AddSubtract> is called like this |
770 | ||
4358a253 | 771 | call_AddSubtract(7, 4); |
d1b91892 AD |
772 | |
773 | then here is the output | |
774 | ||
775 | 7 - 4 = 3 | |
776 | 7 + 4 = 11 | |
a0d0e21e LW |
777 | |
778 | Notes | |
779 | ||
780 | =over 5 | |
781 | ||
782 | =item 1. | |
783 | ||
eb7e169e | 784 | We wanted list context, so G_LIST was used. |
a0d0e21e LW |
785 | |
786 | =item 2. | |
787 | ||
d1b91892 AD |
788 | Not surprisingly C<POPi> is used twice this time because we were |
789 | retrieving 2 values from the stack. The important thing to note is that | |
790 | when using the C<POP*> macros they come off the stack in I<reverse> | |
791 | order. | |
a0d0e21e LW |
792 | |
793 | =back | |
794 | ||
d0554719 | 795 | =head2 Returning a List in Scalar Context |
d1b91892 AD |
796 | |
797 | Say the Perl subroutine in the previous section was called in a scalar | |
798 | context, like this | |
799 | ||
800 | static void | |
801 | call_AddSubScalar(a, b) | |
4358a253 SS |
802 | int a; |
803 | int b; | |
d1b91892 | 804 | { |
4358a253 SS |
805 | dSP; |
806 | int count; | |
807 | int i; | |
d1b91892 | 808 | |
4358a253 | 809 | ENTER; |
d1b91892 AD |
810 | SAVETMPS; |
811 | ||
4358a253 | 812 | PUSHMARK(SP); |
d0554719 TC |
813 | EXTEND(SP, 2); |
814 | PUSHs(sv_2mortal(newSViv(a))); | |
815 | PUSHs(sv_2mortal(newSViv(b))); | |
4358a253 | 816 | PUTBACK; |
d1b91892 | 817 | |
4929bf7b | 818 | count = call_pv("AddSubtract", G_SCALAR); |
d1b91892 | 819 | |
4358a253 | 820 | SPAGAIN; |
d1b91892 | 821 | |
4358a253 | 822 | printf ("Items Returned = %d\n", count); |
d1b91892 | 823 | |
4358a253 SS |
824 | for (i = 1; i <= count; ++i) |
825 | printf ("Value %d = %d\n", i, POPi); | |
d1b91892 | 826 | |
4358a253 SS |
827 | PUTBACK; |
828 | FREETMPS; | |
829 | LEAVE; | |
d1b91892 AD |
830 | } |
831 | ||
832 | The other modification made is that I<call_AddSubScalar> will print the | |
833 | number of items returned from the Perl subroutine and their value (for | |
834 | simplicity it assumes that they are integer). So if | |
835 | I<call_AddSubScalar> is called | |
836 | ||
4358a253 | 837 | call_AddSubScalar(7, 4); |
d1b91892 AD |
838 | |
839 | then the output will be | |
840 | ||
841 | Items Returned = 1 | |
842 | Value 1 = 3 | |
843 | ||
844 | In this case the main point to note is that only the last item in the | |
48052fe5 | 845 | list is returned from the subroutine. I<AddSubtract> actually made it back to |
d1b91892 AD |
846 | I<call_AddSubScalar>. |
847 | ||
848 | ||
02f6dca1 | 849 | =head2 Returning Data from Perl via the Parameter List |
a0d0e21e | 850 | |
48052fe5 FC |
851 | It is also possible to return values directly via the parameter |
852 | list--whether it is actually desirable to do it is another matter entirely. | |
a0d0e21e | 853 | |
d1b91892 AD |
854 | The Perl subroutine, I<Inc>, below takes 2 parameters and increments |
855 | each directly. | |
a0d0e21e | 856 | |
84f709e7 JH |
857 | sub Inc |
858 | { | |
4358a253 SS |
859 | ++ $_[0]; |
860 | ++ $_[1]; | |
a0d0e21e LW |
861 | } |
862 | ||
863 | and here is a C function to call it. | |
864 | ||
865 | static void | |
866 | call_Inc(a, b) | |
4358a253 SS |
867 | int a; |
868 | int b; | |
a0d0e21e | 869 | { |
4358a253 SS |
870 | dSP; |
871 | int count; | |
872 | SV * sva; | |
873 | SV * svb; | |
a0d0e21e | 874 | |
4358a253 | 875 | ENTER; |
a0d0e21e LW |
876 | SAVETMPS; |
877 | ||
4358a253 SS |
878 | sva = sv_2mortal(newSViv(a)); |
879 | svb = sv_2mortal(newSViv(b)); | |
a0d0e21e | 880 | |
4358a253 | 881 | PUSHMARK(SP); |
d0554719 TC |
882 | EXTEND(SP, 2); |
883 | PUSHs(sva); | |
884 | PUSHs(svb); | |
4358a253 | 885 | PUTBACK; |
a0d0e21e | 886 | |
4929bf7b | 887 | count = call_pv("Inc", G_DISCARD); |
a0d0e21e LW |
888 | |
889 | if (count != 0) | |
d1b91892 | 890 | croak ("call_Inc: expected 0 values from 'Inc', got %d\n", |
4358a253 | 891 | count); |
a0d0e21e | 892 | |
4358a253 SS |
893 | printf ("%d + 1 = %d\n", a, SvIV(sva)); |
894 | printf ("%d + 1 = %d\n", b, SvIV(svb)); | |
a0d0e21e | 895 | |
4358a253 SS |
896 | FREETMPS; |
897 | LEAVE; | |
a0d0e21e LW |
898 | } |
899 | ||
d1b91892 | 900 | To be able to access the two parameters that were pushed onto the stack |
4929bf7b | 901 | after they return from I<call_pv> it is necessary to make a note |
19799a22 | 902 | of their addresses--thus the two variables C<sva> and C<svb>. |
a0d0e21e | 903 | |
d1b91892 AD |
904 | The reason this is necessary is that the area of the Perl stack which |
905 | held them will very likely have been overwritten by something else by | |
4929bf7b | 906 | the time control returns from I<call_pv>. |
a0d0e21e LW |
907 | |
908 | ||
909 | ||
910 | ||
d1b91892 | 911 | =head2 Using G_EVAL |
a0d0e21e | 912 | |
d1b91892 AD |
913 | Now an example using G_EVAL. Below is a Perl subroutine which computes |
914 | the difference of its 2 parameters. If this would result in a negative | |
915 | result, the subroutine calls I<die>. | |
a0d0e21e | 916 | |
84f709e7 JH |
917 | sub Subtract |
918 | { | |
4358a253 | 919 | my ($a, $b) = @_; |
a0d0e21e | 920 | |
4358a253 | 921 | die "death can be fatal\n" if $a < $b; |
a0d0e21e | 922 | |
4358a253 | 923 | $a - $b; |
a0d0e21e LW |
924 | } |
925 | ||
926 | and some C to call it | |
927 | ||
e46aa1dd KW |
928 | static void |
929 | call_Subtract(a, b) | |
930 | int a; | |
931 | int b; | |
932 | { | |
933 | dSP; | |
934 | int count; | |
935 | SV *err_tmp; | |
936 | ||
937 | ENTER; | |
938 | SAVETMPS; | |
939 | ||
940 | PUSHMARK(SP); | |
941 | EXTEND(SP, 2); | |
942 | PUSHs(sv_2mortal(newSViv(a))); | |
943 | PUSHs(sv_2mortal(newSViv(b))); | |
944 | PUTBACK; | |
945 | ||
946 | count = call_pv("Subtract", G_EVAL|G_SCALAR); | |
947 | ||
948 | SPAGAIN; | |
949 | ||
950 | /* Check the eval first */ | |
951 | err_tmp = ERRSV; | |
952 | if (SvTRUE(err_tmp)) | |
953 | { | |
954 | printf ("Uh oh - %s\n", SvPV_nolen(err_tmp)); | |
955 | POPs; | |
956 | } | |
957 | else | |
958 | { | |
959 | if (count != 1) | |
960 | croak("call_Subtract: wanted 1 value from 'Subtract', got %d\n", | |
961 | count); | |
962 | ||
963 | printf ("%d - %d = %d\n", a, b, POPi); | |
964 | } | |
965 | ||
966 | PUTBACK; | |
967 | FREETMPS; | |
968 | LEAVE; | |
969 | } | |
a0d0e21e LW |
970 | |
971 | If I<call_Subtract> is called thus | |
972 | ||
d1b91892 | 973 | call_Subtract(4, 5) |
a0d0e21e LW |
974 | |
975 | the following will be printed | |
976 | ||
d1b91892 | 977 | Uh oh - death can be fatal |
a0d0e21e LW |
978 | |
979 | Notes | |
980 | ||
981 | =over 5 | |
982 | ||
983 | =item 1. | |
984 | ||
d1b91892 AD |
985 | We want to be able to catch the I<die> so we have used the G_EVAL |
986 | flag. Not specifying this flag would mean that the program would | |
987 | terminate immediately at the I<die> statement in the subroutine | |
988 | I<Subtract>. | |
a0d0e21e LW |
989 | |
990 | =item 2. | |
991 | ||
54310121 | 992 | The code |
a0d0e21e | 993 | |
d0554719 TC |
994 | err_tmp = ERRSV; |
995 | if (SvTRUE(err_tmp)) | |
d1b91892 | 996 | { |
d0554719 | 997 | printf ("Uh oh - %s\n", SvPV_nolen(err_tmp)); |
4358a253 | 998 | POPs; |
d1b91892 | 999 | } |
a0d0e21e | 1000 | |
d1b91892 | 1001 | is the direct equivalent of this bit of Perl |
a0d0e21e | 1002 | |
4358a253 | 1003 | print "Uh oh - $@\n" if $@; |
a0d0e21e | 1004 | |
d0554719 TC |
1005 | C<PL_errgv> is a perl global of type C<GV *> that points to the symbol |
1006 | table entry containing the error. C<ERRSV> therefore refers to the C | |
3da3c74d | 1007 | equivalent of C<$@>. We use a local temporary, C<err_tmp>, since |
d0554719 TC |
1008 | C<ERRSV> is a macro that calls a function, and C<SvTRUE(ERRSV)> would |
1009 | end up calling that function multiple times. | |
c07a80fd | 1010 | |
cd66fec1 | 1011 | =for apidoc AmnUh|GV *|PL_errgv |
31b83e34 | 1012 | |
d1b91892 | 1013 | =item 3. |
a0d0e21e | 1014 | |
d1b91892 | 1015 | Note that the stack is popped using C<POPs> in the block where |
d0554719 | 1016 | C<SvTRUE(err_tmp)> is true. This is necessary because whenever a |
4929bf7b | 1017 | I<call_*> function invoked with G_EVAL|G_SCALAR returns an error, |
5f05dabc | 1018 | the top of the stack holds the value I<undef>. Because we want the |
d1b91892 | 1019 | program to continue after detecting this error, it is essential that |
6c818a50 | 1020 | the stack be tidied up by removing the I<undef>. |
a0d0e21e LW |
1021 | |
1022 | =back | |
1023 | ||
1024 | ||
c07a80fd | 1025 | =head2 Using G_KEEPERR |
1026 | ||
1027 | Consider this rather facetious example, where we have used an XS | |
1028 | version of the call_Subtract example above inside a destructor: | |
1029 | ||
1030 | package Foo; | |
84f709e7 | 1031 | sub new { bless {}, $_[0] } |
54310121 | 1032 | sub Subtract { |
84f709e7 | 1033 | my($a,$b) = @_; |
4358a253 | 1034 | die "death can be fatal" if $a < $b; |
84f709e7 | 1035 | $a - $b; |
c07a80fd | 1036 | } |
84f709e7 JH |
1037 | sub DESTROY { call_Subtract(5, 4); } |
1038 | sub foo { die "foo dies"; } | |
c07a80fd | 1039 | |
1040 | package main; | |
7ce09284 Z |
1041 | { |
1042 | my $foo = Foo->new; | |
1043 | eval { $foo->foo }; | |
1044 | } | |
c07a80fd | 1045 | print "Saw: $@" if $@; # should be, but isn't |
1046 | ||
1047 | This example will fail to recognize that an error occurred inside the | |
1048 | C<eval {}>. Here's why: the call_Subtract code got executed while perl | |
7ce09284 | 1049 | was cleaning up temporaries when exiting the outer braced block, and because |
4929bf7b | 1050 | call_Subtract is implemented with I<call_pv> using the G_EVAL |
c07a80fd | 1051 | flag, it promptly reset C<$@>. This results in the failure of the |
1052 | outermost test for C<$@>, and thereby the failure of the error trap. | |
1053 | ||
4929bf7b | 1054 | Appending the G_KEEPERR flag, so that the I<call_pv> call in |
c07a80fd | 1055 | call_Subtract reads: |
1056 | ||
4929bf7b | 1057 | count = call_pv("Subtract", G_EVAL|G_SCALAR|G_KEEPERR); |
c07a80fd | 1058 | |
1059 | will preserve the error and restore reliable error handling. | |
1060 | ||
4929bf7b | 1061 | =head2 Using call_sv |
a0d0e21e | 1062 | |
d1b91892 AD |
1063 | In all the previous examples I have 'hard-wired' the name of the Perl |
1064 | subroutine to be called from C. Most of the time though, it is more | |
1065 | convenient to be able to specify the name of the Perl subroutine from | |
d0554719 TC |
1066 | within the Perl script, and you'll want to use |
1067 | L<call_sv|perlapi/call_sv>. | |
a0d0e21e LW |
1068 | |
1069 | Consider the Perl code below | |
1070 | ||
84f709e7 JH |
1071 | sub fred |
1072 | { | |
4358a253 | 1073 | print "Hello there\n"; |
d1b91892 AD |
1074 | } |
1075 | ||
4358a253 | 1076 | CallSubPV("fred"); |
d1b91892 AD |
1077 | |
1078 | Here is a snippet of XSUB which defines I<CallSubPV>. | |
1079 | ||
1080 | void | |
1081 | CallSubPV(name) | |
1082 | char * name | |
1083 | CODE: | |
4358a253 SS |
1084 | PUSHMARK(SP); |
1085 | call_pv(name, G_DISCARD|G_NOARGS); | |
a0d0e21e | 1086 | |
54310121 | 1087 | That is fine as far as it goes. The thing is, the Perl subroutine |
94a37a2f BF |
1088 | can be specified as only a string, however, Perl allows references |
1089 | to subroutines and anonymous subroutines. | |
4929bf7b | 1090 | This is where I<call_sv> is useful. |
d1b91892 AD |
1091 | |
1092 | The code below for I<CallSubSV> is identical to I<CallSubPV> except | |
1093 | that the C<name> parameter is now defined as an SV* and we use | |
4929bf7b | 1094 | I<call_sv> instead of I<call_pv>. |
d1b91892 AD |
1095 | |
1096 | void | |
1097 | CallSubSV(name) | |
1098 | SV * name | |
1099 | CODE: | |
4358a253 SS |
1100 | PUSHMARK(SP); |
1101 | call_sv(name, G_DISCARD|G_NOARGS); | |
a0d0e21e | 1102 | |
1d45ec27 | 1103 | Because we are using an SV to call I<fred> the following can all be used: |
a0d0e21e | 1104 | |
4358a253 SS |
1105 | CallSubSV("fred"); |
1106 | CallSubSV(\&fred); | |
1107 | $ref = \&fred; | |
1108 | CallSubSV($ref); | |
1109 | CallSubSV( sub { print "Hello there\n" } ); | |
a0d0e21e | 1110 | |
4929bf7b | 1111 | As you can see, I<call_sv> gives you much greater flexibility in |
d1b91892 AD |
1112 | how you can specify the Perl subroutine. |
1113 | ||
1d45ec27 | 1114 | You should note that, if it is necessary to store the SV (C<name> in the |
d1b91892 | 1115 | example above) which corresponds to the Perl subroutine so that it can |
5f05dabc | 1116 | be used later in the program, it not enough just to store a copy of the |
1d45ec27 | 1117 | pointer to the SV. Say the code above had been like this: |
d1b91892 | 1118 | |
4358a253 | 1119 | static SV * rememberSub; |
d1b91892 AD |
1120 | |
1121 | void | |
1122 | SaveSub1(name) | |
1123 | SV * name | |
1124 | CODE: | |
4358a253 | 1125 | rememberSub = name; |
d1b91892 AD |
1126 | |
1127 | void | |
1128 | CallSavedSub1() | |
1129 | CODE: | |
4358a253 SS |
1130 | PUSHMARK(SP); |
1131 | call_sv(rememberSub, G_DISCARD|G_NOARGS); | |
a0d0e21e | 1132 | |
1d45ec27 | 1133 | The reason this is wrong is that, by the time you come to use the |
d1b91892 AD |
1134 | pointer C<rememberSub> in C<CallSavedSub1>, it may or may not still refer |
1135 | to the Perl subroutine that was recorded in C<SaveSub1>. This is | |
1d45ec27 | 1136 | particularly true for these cases: |
a0d0e21e | 1137 | |
4358a253 SS |
1138 | SaveSub1(\&fred); |
1139 | CallSavedSub1(); | |
a0d0e21e | 1140 | |
4358a253 SS |
1141 | SaveSub1( sub { print "Hello there\n" } ); |
1142 | CallSavedSub1(); | |
a0d0e21e | 1143 | |
1d45ec27 | 1144 | By the time each of the C<SaveSub1> statements above has been executed, |
54310121 | 1145 | the SV*s which corresponded to the parameters will no longer exist. |
d1b91892 | 1146 | Expect an error message from Perl of the form |
a0d0e21e | 1147 | |
d1b91892 | 1148 | Can't use an undefined value as a subroutine reference at ... |
a0d0e21e | 1149 | |
d1b91892 | 1150 | for each of the C<CallSavedSub1> lines. |
a0d0e21e | 1151 | |
54310121 | 1152 | Similarly, with this code |
a0d0e21e | 1153 | |
4358a253 SS |
1154 | $ref = \&fred; |
1155 | SaveSub1($ref); | |
1156 | $ref = 47; | |
1157 | CallSavedSub1(); | |
a0d0e21e | 1158 | |
54310121 | 1159 | you can expect one of these messages (which you actually get is dependent on |
1160 | the version of Perl you are using) | |
a0d0e21e | 1161 | |
d1b91892 AD |
1162 | Not a CODE reference at ... |
1163 | Undefined subroutine &main::47 called ... | |
a0d0e21e | 1164 | |
19799a22 | 1165 | The variable $ref may have referred to the subroutine C<fred> |
d1b91892 | 1166 | whenever the call to C<SaveSub1> was made but by the time |
5f05dabc | 1167 | C<CallSavedSub1> gets called it now holds the number C<47>. Because we |
d1b91892 | 1168 | saved only a pointer to the original SV in C<SaveSub1>, any changes to |
19799a22 | 1169 | $ref will be tracked by the pointer C<rememberSub>. This means that |
d1b91892 AD |
1170 | whenever C<CallSavedSub1> gets called, it will attempt to execute the |
1171 | code which is referenced by the SV* C<rememberSub>. In this case | |
1172 | though, it now refers to the integer C<47>, so expect Perl to complain | |
1173 | loudly. | |
a0d0e21e | 1174 | |
1d45ec27 | 1175 | A similar but more subtle problem is illustrated with this code: |
a0d0e21e | 1176 | |
4358a253 SS |
1177 | $ref = \&fred; |
1178 | SaveSub1($ref); | |
1179 | $ref = \&joe; | |
1180 | CallSavedSub1(); | |
a0d0e21e | 1181 | |
1d45ec27 | 1182 | This time whenever C<CallSavedSub1> gets called it will execute the Perl |
54310121 | 1183 | subroutine C<joe> (assuming it exists) rather than C<fred> as was |
d1b91892 | 1184 | originally requested in the call to C<SaveSub1>. |
a0d0e21e | 1185 | |
d1b91892 | 1186 | To get around these problems it is necessary to take a full copy of the |
1d45ec27 | 1187 | SV. The code below shows C<SaveSub2> modified to do that. |
a0d0e21e | 1188 | |
d0554719 | 1189 | /* this isn't thread-safe */ |
4358a253 | 1190 | static SV * keepSub = (SV*)NULL; |
d1b91892 AD |
1191 | |
1192 | void | |
1193 | SaveSub2(name) | |
1194 | SV * name | |
1195 | CODE: | |
1196 | /* Take a copy of the callback */ | |
1197 | if (keepSub == (SV*)NULL) | |
1198 | /* First time, so create a new SV */ | |
4358a253 | 1199 | keepSub = newSVsv(name); |
d1b91892 AD |
1200 | else |
1201 | /* Been here before, so overwrite */ | |
4358a253 | 1202 | SvSetSV(keepSub, name); |
d1b91892 AD |
1203 | |
1204 | void | |
1205 | CallSavedSub2() | |
1206 | CODE: | |
4358a253 SS |
1207 | PUSHMARK(SP); |
1208 | call_sv(keepSub, G_DISCARD|G_NOARGS); | |
d1b91892 | 1209 | |
5f05dabc | 1210 | To avoid creating a new SV every time C<SaveSub2> is called, |
d1b91892 AD |
1211 | the function first checks to see if it has been called before. If not, |
1212 | then space for a new SV is allocated and the reference to the Perl | |
1d45ec27 FC |
1213 | subroutine C<name> is copied to the variable C<keepSub> in one |
1214 | operation using C<newSVsv>. Thereafter, whenever C<SaveSub2> is called, | |
d1b91892 AD |
1215 | the existing SV, C<keepSub>, is overwritten with the new value using |
1216 | C<SvSetSV>. | |
1217 | ||
d0554719 TC |
1218 | Note: using a static or global variable to store the SV isn't |
1219 | thread-safe. You can either use the C<MY_CXT> mechanism documented in | |
1220 | L<perlxs/Safely Storing Static Data in XS> which is fast, or store the | |
1221 | values in perl global variables, using get_sv(), which is much slower. | |
1222 | ||
4929bf7b | 1223 | =head2 Using call_argv |
d1b91892 AD |
1224 | |
1225 | Here is a Perl subroutine which prints whatever parameters are passed | |
1226 | to it. | |
1227 | ||
84f709e7 JH |
1228 | sub PrintList |
1229 | { | |
4358a253 | 1230 | my(@list) = @_; |
d1b91892 | 1231 | |
84f709e7 | 1232 | foreach (@list) { print "$_\n" } |
d1b91892 AD |
1233 | } |
1234 | ||
1d45ec27 | 1235 | And here is an example of I<call_argv> which will call |
d1b91892 AD |
1236 | I<PrintList>. |
1237 | ||
4358a253 | 1238 | static char * words[] = {"alpha", "beta", "gamma", "delta", NULL}; |
d1b91892 AD |
1239 | |
1240 | static void | |
1241 | call_PrintList() | |
1242 | { | |
4358a253 | 1243 | call_argv("PrintList", G_DISCARD, words); |
d1b91892 AD |
1244 | } |
1245 | ||
1246 | Note that it is not necessary to call C<PUSHMARK> in this instance. | |
4929bf7b | 1247 | This is because I<call_argv> will do it for you. |
d1b91892 | 1248 | |
4929bf7b | 1249 | =head2 Using call_method |
a0d0e21e | 1250 | |
1d45ec27 | 1251 | Consider the following Perl code: |
a0d0e21e | 1252 | |
d1b91892 | 1253 | { |
4358a253 | 1254 | package Mine; |
84f709e7 JH |
1255 | |
1256 | sub new | |
1257 | { | |
4358a253 | 1258 | my($type) = shift; |
84f709e7 JH |
1259 | bless [@_] |
1260 | } | |
1261 | ||
1262 | sub Display | |
1263 | { | |
4358a253 SS |
1264 | my ($self, $index) = @_; |
1265 | print "$index: $$self[$index]\n"; | |
84f709e7 JH |
1266 | } |
1267 | ||
1268 | sub PrintID | |
1269 | { | |
4358a253 SS |
1270 | my($class) = @_; |
1271 | print "This is Class $class version 1.0\n"; | |
84f709e7 | 1272 | } |
d1b91892 AD |
1273 | } |
1274 | ||
5f05dabc | 1275 | It implements just a very simple class to manage an array. Apart from |
d1b91892 | 1276 | the constructor, C<new>, it declares methods, one static and one |
5f05dabc | 1277 | virtual. The static method, C<PrintID>, prints out simply the class |
d1b91892 | 1278 | name and a version number. The virtual method, C<Display>, prints out a |
1d45ec27 | 1279 | single element of the array. Here is an all-Perl example of using it. |
d1b91892 | 1280 | |
797f796a | 1281 | $a = Mine->new('red', 'green', 'blue'); |
4358a253 | 1282 | $a->Display(1); |
797f796a | 1283 | Mine->PrintID; |
a0d0e21e | 1284 | |
d1b91892 | 1285 | will print |
a0d0e21e | 1286 | |
d1b91892 | 1287 | 1: green |
54310121 | 1288 | This is Class Mine version 1.0 |
a0d0e21e | 1289 | |
d1b91892 | 1290 | Calling a Perl method from C is fairly straightforward. The following |
1d45ec27 | 1291 | things are required: |
a0d0e21e | 1292 | |
d1b91892 AD |
1293 | =over 5 |
1294 | ||
1295 | =item * | |
1296 | ||
1d45ec27 FC |
1297 | A reference to the object for a virtual method or the name of the class |
1298 | for a static method | |
d1b91892 AD |
1299 | |
1300 | =item * | |
1301 | ||
1d45ec27 | 1302 | The name of the method |
d1b91892 AD |
1303 | |
1304 | =item * | |
1305 | ||
1d45ec27 | 1306 | Any other parameters specific to the method |
d1b91892 AD |
1307 | |
1308 | =back | |
1309 | ||
1310 | Here is a simple XSUB which illustrates the mechanics of calling both | |
1311 | the C<PrintID> and C<Display> methods from C. | |
1312 | ||
1313 | void | |
1314 | call_Method(ref, method, index) | |
1315 | SV * ref | |
1316 | char * method | |
1317 | int index | |
1318 | CODE: | |
924508f0 | 1319 | PUSHMARK(SP); |
d0554719 TC |
1320 | EXTEND(SP, 2); |
1321 | PUSHs(ref); | |
1322 | PUSHs(sv_2mortal(newSViv(index))); | |
d1b91892 AD |
1323 | PUTBACK; |
1324 | ||
4358a253 | 1325 | call_method(method, G_DISCARD); |
d1b91892 AD |
1326 | |
1327 | void | |
1328 | call_PrintID(class, method) | |
1329 | char * class | |
1330 | char * method | |
1331 | CODE: | |
924508f0 | 1332 | PUSHMARK(SP); |
4358a253 | 1333 | XPUSHs(sv_2mortal(newSVpv(class, 0))); |
d1b91892 AD |
1334 | PUTBACK; |
1335 | ||
4358a253 | 1336 | call_method(method, G_DISCARD); |
d1b91892 AD |
1337 | |
1338 | ||
1d45ec27 | 1339 | So the methods C<PrintID> and C<Display> can be invoked like this: |
d1b91892 | 1340 | |
797f796a | 1341 | $a = Mine->new('red', 'green', 'blue'); |
4358a253 SS |
1342 | call_Method($a, 'Display', 1); |
1343 | call_PrintID('Mine', 'PrintID'); | |
d1b91892 | 1344 | |
1d45ec27 | 1345 | The only thing to note is that, in both the static and virtual methods, |
19799a22 | 1346 | the method name is not passed via the stack--it is used as the first |
4929bf7b | 1347 | parameter to I<call_method>. |
d1b91892 | 1348 | |
54310121 | 1349 | =head2 Using GIMME_V |
d1b91892 | 1350 | |
54310121 | 1351 | Here is a trivial XSUB which prints the context in which it is |
d1b91892 AD |
1352 | currently executing. |
1353 | ||
1354 | void | |
1355 | PrintContext() | |
1356 | CODE: | |
1c23e2bd | 1357 | U8 gimme = GIMME_V; |
54310121 | 1358 | if (gimme == G_VOID) |
4358a253 | 1359 | printf ("Context is Void\n"); |
54310121 | 1360 | else if (gimme == G_SCALAR) |
4358a253 | 1361 | printf ("Context is Scalar\n"); |
d1b91892 | 1362 | else |
4358a253 | 1363 | printf ("Context is Array\n"); |
d1b91892 | 1364 | |
1d45ec27 | 1365 | And here is some Perl to test it. |
d1b91892 | 1366 | |
4358a253 SS |
1367 | PrintContext; |
1368 | $a = PrintContext; | |
1369 | @a = PrintContext; | |
d1b91892 AD |
1370 | |
1371 | The output from that will be | |
1372 | ||
54310121 | 1373 | Context is Void |
d1b91892 AD |
1374 | Context is Scalar |
1375 | Context is Array | |
1376 | ||
02f6dca1 | 1377 | =head2 Using Perl to Dispose of Temporaries |
d1b91892 AD |
1378 | |
1379 | In the examples given to date, any temporaries created in the callback | |
4929bf7b | 1380 | (i.e., parameters passed on the stack to the I<call_*> function or |
1d45ec27 | 1381 | values returned via the stack) have been freed by one of these methods: |
d1b91892 AD |
1382 | |
1383 | =over 5 | |
1384 | ||
1385 | =item * | |
1386 | ||
1d45ec27 | 1387 | Specifying the G_DISCARD flag with I<call_*> |
d1b91892 AD |
1388 | |
1389 | =item * | |
1390 | ||
1d45ec27 | 1391 | Explicitly using the C<ENTER>/C<SAVETMPS>--C<FREETMPS>/C<LEAVE> pairing |
d1b91892 AD |
1392 | |
1393 | =back | |
1394 | ||
1395 | There is another method which can be used, namely letting Perl do it | |
1396 | for you automatically whenever it regains control after the callback | |
1397 | has terminated. This is done by simply not using the | |
1398 | ||
4358a253 SS |
1399 | ENTER; |
1400 | SAVETMPS; | |
d1b91892 | 1401 | ... |
4358a253 SS |
1402 | FREETMPS; |
1403 | LEAVE; | |
d1b91892 AD |
1404 | |
1405 | sequence in the callback (and not, of course, specifying the G_DISCARD | |
1406 | flag). | |
1407 | ||
1408 | If you are going to use this method you have to be aware of a possible | |
1409 | memory leak which can arise under very specific circumstances. To | |
1410 | explain these circumstances you need to know a bit about the flow of | |
1411 | control between Perl and the callback routine. | |
1412 | ||
1413 | The examples given at the start of the document (an error handler and | |
1414 | an event driven program) are typical of the two main sorts of flow | |
1415 | control that you are likely to encounter with callbacks. There is a | |
1416 | very important distinction between them, so pay attention. | |
1417 | ||
1418 | In the first example, an error handler, the flow of control could be as | |
1419 | follows. You have created an interface to an external library. | |
1420 | Control can reach the external library like this | |
1421 | ||
1422 | perl --> XSUB --> external library | |
1423 | ||
1424 | Whilst control is in the library, an error condition occurs. You have | |
1425 | previously set up a Perl callback to handle this situation, so it will | |
1426 | get executed. Once the callback has finished, control will drop back to | |
1427 | Perl again. Here is what the flow of control will be like in that | |
1428 | situation | |
1429 | ||
1430 | perl --> XSUB --> external library | |
1431 | ... | |
1432 | error occurs | |
1433 | ... | |
4929bf7b | 1434 | external library --> call_* --> perl |
d1b91892 | 1435 | | |
4929bf7b | 1436 | perl <-- XSUB <-- external library <-- call_* <----+ |
d1b91892 | 1437 | |
4929bf7b | 1438 | After processing of the error using I<call_*> is completed, |
d1b91892 AD |
1439 | control reverts back to Perl more or less immediately. |
1440 | ||
1441 | In the diagram, the further right you go the more deeply nested the | |
1442 | scope is. It is only when control is back with perl on the extreme | |
1443 | left of the diagram that you will have dropped back to the enclosing | |
1444 | scope and any temporaries you have left hanging around will be freed. | |
1445 | ||
1446 | In the second example, an event driven program, the flow of control | |
1447 | will be more like this | |
1448 | ||
1449 | perl --> XSUB --> event handler | |
1450 | ... | |
4929bf7b | 1451 | event handler --> call_* --> perl |
d1b91892 | 1452 | | |
4929bf7b | 1453 | event handler <-- call_* <----+ |
d1b91892 | 1454 | ... |
4929bf7b | 1455 | event handler --> call_* --> perl |
d1b91892 | 1456 | | |
4929bf7b | 1457 | event handler <-- call_* <----+ |
d1b91892 | 1458 | ... |
4929bf7b | 1459 | event handler --> call_* --> perl |
d1b91892 | 1460 | | |
4929bf7b | 1461 | event handler <-- call_* <----+ |
d1b91892 AD |
1462 | |
1463 | In this case the flow of control can consist of only the repeated | |
1464 | sequence | |
1465 | ||
4929bf7b | 1466 | event handler --> call_* --> perl |
d1b91892 | 1467 | |
54310121 | 1468 | for practically the complete duration of the program. This means that |
1469 | control may I<never> drop back to the surrounding scope in Perl at the | |
1470 | extreme left. | |
d1b91892 AD |
1471 | |
1472 | So what is the big problem? Well, if you are expecting Perl to tidy up | |
1473 | those temporaries for you, you might be in for a long wait. For Perl | |
5f05dabc | 1474 | to dispose of your temporaries, control must drop back to the |
d1b91892 | 1475 | enclosing scope at some stage. In the event driven scenario that may |
1d45ec27 | 1476 | never happen. This means that, as time goes on, your program will |
d1b91892 AD |
1477 | create more and more temporaries, none of which will ever be freed. As |
1478 | each of these temporaries consumes some memory your program will | |
19799a22 | 1479 | eventually consume all the available memory in your system--kapow! |
d1b91892 | 1480 | |
19799a22 | 1481 | So here is the bottom line--if you are sure that control will revert |
d1b91892 | 1482 | back to the enclosing Perl scope fairly quickly after the end of your |
5f05dabc | 1483 | callback, then it isn't absolutely necessary to dispose explicitly of |
d1b91892 AD |
1484 | any temporaries you may have created. Mind you, if you are at all |
1485 | uncertain about what to do, it doesn't do any harm to tidy up anyway. | |
1486 | ||
1487 | ||
02f6dca1 | 1488 | =head2 Strategies for Storing Callback Context Information |
d1b91892 AD |
1489 | |
1490 | ||
1491 | Potentially one of the trickiest problems to overcome when designing a | |
1492 | callback interface can be figuring out how to store the mapping between | |
1493 | the C callback function and the Perl equivalent. | |
1494 | ||
1495 | To help understand why this can be a real problem first consider how a | |
1496 | callback is set up in an all C environment. Typically a C API will | |
1497 | provide a function to register a callback. This will expect a pointer | |
1498 | to a function as one of its parameters. Below is a call to a | |
1499 | hypothetical function C<register_fatal> which registers the C function | |
1500 | to get called when a fatal error occurs. | |
1501 | ||
4358a253 | 1502 | register_fatal(cb1); |
d1b91892 AD |
1503 | |
1504 | The single parameter C<cb1> is a pointer to a function, so you must | |
1505 | have defined C<cb1> in your code, say something like this | |
1506 | ||
1507 | static void | |
1508 | cb1() | |
1509 | { | |
4358a253 SS |
1510 | printf ("Fatal Error\n"); |
1511 | exit(1); | |
d1b91892 AD |
1512 | } |
1513 | ||
1514 | Now change that to call a Perl subroutine instead | |
1515 | ||
1516 | static SV * callback = (SV*)NULL; | |
1517 | ||
1518 | static void | |
1519 | cb1() | |
1520 | { | |
4358a253 | 1521 | dSP; |
d1b91892 | 1522 | |
4358a253 | 1523 | PUSHMARK(SP); |
d1b91892 AD |
1524 | |
1525 | /* Call the Perl sub to process the callback */ | |
4358a253 | 1526 | call_sv(callback, G_DISCARD); |
d1b91892 AD |
1527 | } |
1528 | ||
1529 | ||
1530 | void | |
1531 | register_fatal(fn) | |
1532 | SV * fn | |
1533 | CODE: | |
1534 | /* Remember the Perl sub */ | |
1535 | if (callback == (SV*)NULL) | |
4358a253 | 1536 | callback = newSVsv(fn); |
d1b91892 | 1537 | else |
4358a253 | 1538 | SvSetSV(callback, fn); |
d1b91892 AD |
1539 | |
1540 | /* register the callback with the external library */ | |
4358a253 | 1541 | register_fatal(cb1); |
d1b91892 AD |
1542 | |
1543 | where the Perl equivalent of C<register_fatal> and the callback it | |
1544 | registers, C<pcb1>, might look like this | |
1545 | ||
1546 | # Register the sub pcb1 | |
4358a253 | 1547 | register_fatal(\&pcb1); |
d1b91892 | 1548 | |
84f709e7 JH |
1549 | sub pcb1 |
1550 | { | |
4358a253 | 1551 | die "I'm dying...\n"; |
d1b91892 AD |
1552 | } |
1553 | ||
1554 | The mapping between the C callback and the Perl equivalent is stored in | |
1555 | the global variable C<callback>. | |
1556 | ||
5f05dabc | 1557 | This will be adequate if you ever need to have only one callback |
d1b91892 AD |
1558 | registered at any time. An example could be an error handler like the |
1559 | code sketched out above. Remember though, repeated calls to | |
1560 | C<register_fatal> will replace the previously registered callback | |
1561 | function with the new one. | |
1562 | ||
1563 | Say for example you want to interface to a library which allows asynchronous | |
1564 | file i/o. In this case you may be able to register a callback whenever | |
1565 | a read operation has completed. To be of any use we want to be able to | |
1566 | call separate Perl subroutines for each file that is opened. As it | |
1567 | stands, the error handler example above would not be adequate as it | |
1568 | allows only a single callback to be defined at any time. What we | |
1569 | require is a means of storing the mapping between the opened file and | |
1570 | the Perl subroutine we want to be called for that file. | |
1571 | ||
1572 | Say the i/o library has a function C<asynch_read> which associates a C | |
19799a22 | 1573 | function C<ProcessRead> with a file handle C<fh>--this assumes that it |
d1b91892 AD |
1574 | has also provided some routine to open the file and so obtain the file |
1575 | handle. | |
1576 | ||
1577 | asynch_read(fh, ProcessRead) | |
1578 | ||
1579 | This may expect the C I<ProcessRead> function of this form | |
1580 | ||
1581 | void | |
1582 | ProcessRead(fh, buffer) | |
4358a253 SS |
1583 | int fh; |
1584 | char * buffer; | |
d1b91892 | 1585 | { |
54310121 | 1586 | ... |
d1b91892 AD |
1587 | } |
1588 | ||
1589 | To provide a Perl interface to this library we need to be able to map | |
1590 | between the C<fh> parameter and the Perl subroutine we want called. A | |
1591 | hash is a convenient mechanism for storing this mapping. The code | |
1592 | below shows a possible implementation | |
1593 | ||
4358a253 | 1594 | static HV * Mapping = (HV*)NULL; |
a0d0e21e | 1595 | |
d1b91892 AD |
1596 | void |
1597 | asynch_read(fh, callback) | |
1598 | int fh | |
1599 | SV * callback | |
1600 | CODE: | |
1601 | /* If the hash doesn't already exist, create it */ | |
1602 | if (Mapping == (HV*)NULL) | |
4358a253 | 1603 | Mapping = newHV(); |
d1b91892 AD |
1604 | |
1605 | /* Save the fh -> callback mapping */ | |
4358a253 | 1606 | hv_store(Mapping, (char*)&fh, sizeof(fh), newSVsv(callback), 0); |
d1b91892 AD |
1607 | |
1608 | /* Register with the C Library */ | |
4358a253 | 1609 | asynch_read(fh, asynch_read_if); |
d1b91892 AD |
1610 | |
1611 | and C<asynch_read_if> could look like this | |
1612 | ||
1613 | static void | |
1614 | asynch_read_if(fh, buffer) | |
4358a253 SS |
1615 | int fh; |
1616 | char * buffer; | |
d1b91892 | 1617 | { |
4358a253 SS |
1618 | dSP; |
1619 | SV ** sv; | |
d1b91892 AD |
1620 | |
1621 | /* Get the callback associated with fh */ | |
4358a253 | 1622 | sv = hv_fetch(Mapping, (char*)&fh , sizeof(fh), FALSE); |
d1b91892 | 1623 | if (sv == (SV**)NULL) |
4358a253 | 1624 | croak("Internal error...\n"); |
d1b91892 | 1625 | |
4358a253 | 1626 | PUSHMARK(SP); |
d0554719 TC |
1627 | EXTEND(SP, 2); |
1628 | PUSHs(sv_2mortal(newSViv(fh))); | |
1629 | PUSHs(sv_2mortal(newSVpv(buffer, 0))); | |
4358a253 | 1630 | PUTBACK; |
d1b91892 AD |
1631 | |
1632 | /* Call the Perl sub */ | |
4358a253 | 1633 | call_sv(*sv, G_DISCARD); |
d1b91892 AD |
1634 | } |
1635 | ||
1636 | For completeness, here is C<asynch_close>. This shows how to remove | |
1637 | the entry from the hash C<Mapping>. | |
1638 | ||
1639 | void | |
1640 | asynch_close(fh) | |
1641 | int fh | |
1642 | CODE: | |
1643 | /* Remove the entry from the hash */ | |
4358a253 | 1644 | (void) hv_delete(Mapping, (char*)&fh, sizeof(fh), G_DISCARD); |
a0d0e21e | 1645 | |
d1b91892 | 1646 | /* Now call the real asynch_close */ |
4358a253 | 1647 | asynch_close(fh); |
a0d0e21e | 1648 | |
d1b91892 AD |
1649 | So the Perl interface would look like this |
1650 | ||
84f709e7 JH |
1651 | sub callback1 |
1652 | { | |
4358a253 | 1653 | my($handle, $buffer) = @_; |
d1b91892 | 1654 | } |
a0d0e21e | 1655 | |
d1b91892 | 1656 | # Register the Perl callback |
4358a253 | 1657 | asynch_read($fh, \&callback1); |
a0d0e21e | 1658 | |
4358a253 | 1659 | asynch_close($fh); |
d1b91892 AD |
1660 | |
1661 | The mapping between the C callback and Perl is stored in the global | |
1662 | hash C<Mapping> this time. Using a hash has the distinct advantage that | |
1663 | it allows an unlimited number of callbacks to be registered. | |
1664 | ||
1665 | What if the interface provided by the C callback doesn't contain a | |
1666 | parameter which allows the file handle to Perl subroutine mapping? Say | |
1667 | in the asynchronous i/o package, the callback function gets passed only | |
1668 | the C<buffer> parameter like this | |
1669 | ||
1670 | void | |
1671 | ProcessRead(buffer) | |
4358a253 | 1672 | char * buffer; |
d1b91892 AD |
1673 | { |
1674 | ... | |
1675 | } | |
a0d0e21e | 1676 | |
d1b91892 AD |
1677 | Without the file handle there is no straightforward way to map from the |
1678 | C callback to the Perl subroutine. | |
a0d0e21e | 1679 | |
54310121 | 1680 | In this case a possible way around this problem is to predefine a |
d1b91892 AD |
1681 | series of C functions to act as the interface to Perl, thus |
1682 | ||
1683 | #define MAX_CB 3 | |
1684 | #define NULL_HANDLE -1 | |
4358a253 | 1685 | typedef void (*FnMap)(); |
d1b91892 AD |
1686 | |
1687 | struct MapStruct { | |
4358a253 SS |
1688 | FnMap Function; |
1689 | SV * PerlSub; | |
1690 | int Handle; | |
1691 | }; | |
d1b91892 | 1692 | |
4358a253 SS |
1693 | static void fn1(); |
1694 | static void fn2(); | |
1695 | static void fn3(); | |
d1b91892 AD |
1696 | |
1697 | static struct MapStruct Map [MAX_CB] = | |
1698 | { | |
1699 | { fn1, NULL, NULL_HANDLE }, | |
1700 | { fn2, NULL, NULL_HANDLE }, | |
1701 | { fn3, NULL, NULL_HANDLE } | |
4358a253 | 1702 | }; |
d1b91892 AD |
1703 | |
1704 | static void | |
1705 | Pcb(index, buffer) | |
4358a253 SS |
1706 | int index; |
1707 | char * buffer; | |
d1b91892 | 1708 | { |
4358a253 | 1709 | dSP; |
d1b91892 | 1710 | |
4358a253 SS |
1711 | PUSHMARK(SP); |
1712 | XPUSHs(sv_2mortal(newSVpv(buffer, 0))); | |
1713 | PUTBACK; | |
d1b91892 AD |
1714 | |
1715 | /* Call the Perl sub */ | |
4358a253 | 1716 | call_sv(Map[index].PerlSub, G_DISCARD); |
d1b91892 AD |
1717 | } |
1718 | ||
1719 | static void | |
1720 | fn1(buffer) | |
4358a253 | 1721 | char * buffer; |
d1b91892 | 1722 | { |
4358a253 | 1723 | Pcb(0, buffer); |
d1b91892 AD |
1724 | } |
1725 | ||
1726 | static void | |
1727 | fn2(buffer) | |
4358a253 | 1728 | char * buffer; |
d1b91892 | 1729 | { |
4358a253 | 1730 | Pcb(1, buffer); |
d1b91892 AD |
1731 | } |
1732 | ||
1733 | static void | |
1734 | fn3(buffer) | |
4358a253 | 1735 | char * buffer; |
d1b91892 | 1736 | { |
4358a253 | 1737 | Pcb(2, buffer); |
d1b91892 AD |
1738 | } |
1739 | ||
1740 | void | |
1741 | array_asynch_read(fh, callback) | |
1742 | int fh | |
1743 | SV * callback | |
1744 | CODE: | |
4358a253 SS |
1745 | int index; |
1746 | int null_index = MAX_CB; | |
d1b91892 AD |
1747 | |
1748 | /* Find the same handle or an empty entry */ | |
4358a253 | 1749 | for (index = 0; index < MAX_CB; ++index) |
d1b91892 AD |
1750 | { |
1751 | if (Map[index].Handle == fh) | |
4358a253 | 1752 | break; |
d1b91892 AD |
1753 | |
1754 | if (Map[index].Handle == NULL_HANDLE) | |
4358a253 | 1755 | null_index = index; |
d1b91892 AD |
1756 | } |
1757 | ||
1758 | if (index == MAX_CB && null_index == MAX_CB) | |
4358a253 | 1759 | croak ("Too many callback functions registered\n"); |
d1b91892 AD |
1760 | |
1761 | if (index == MAX_CB) | |
4358a253 | 1762 | index = null_index; |
d1b91892 AD |
1763 | |
1764 | /* Save the file handle */ | |
4358a253 | 1765 | Map[index].Handle = fh; |
d1b91892 AD |
1766 | |
1767 | /* Remember the Perl sub */ | |
1768 | if (Map[index].PerlSub == (SV*)NULL) | |
4358a253 | 1769 | Map[index].PerlSub = newSVsv(callback); |
d1b91892 | 1770 | else |
4358a253 | 1771 | SvSetSV(Map[index].PerlSub, callback); |
d1b91892 | 1772 | |
4358a253 | 1773 | asynch_read(fh, Map[index].Function); |
d1b91892 AD |
1774 | |
1775 | void | |
1776 | array_asynch_close(fh) | |
1777 | int fh | |
1778 | CODE: | |
4358a253 | 1779 | int index; |
d1b91892 AD |
1780 | |
1781 | /* Find the file handle */ | |
4358a253 | 1782 | for (index = 0; index < MAX_CB; ++ index) |
d1b91892 | 1783 | if (Map[index].Handle == fh) |
4358a253 | 1784 | break; |
d1b91892 AD |
1785 | |
1786 | if (index == MAX_CB) | |
4358a253 | 1787 | croak ("could not close fh %d\n", fh); |
d1b91892 | 1788 | |
4358a253 SS |
1789 | Map[index].Handle = NULL_HANDLE; |
1790 | SvREFCNT_dec(Map[index].PerlSub); | |
1791 | Map[index].PerlSub = (SV*)NULL; | |
d1b91892 | 1792 | |
4358a253 | 1793 | asynch_close(fh); |
d1b91892 | 1794 | |
5f05dabc | 1795 | In this case the functions C<fn1>, C<fn2>, and C<fn3> are used to |
d1b91892 | 1796 | remember the Perl subroutine to be called. Each of the functions holds |
4a6725af | 1797 | a separate hard-wired index which is used in the function C<Pcb> to |
d1b91892 AD |
1798 | access the C<Map> array and actually call the Perl subroutine. |
1799 | ||
1800 | There are some obvious disadvantages with this technique. | |
1801 | ||
1802 | Firstly, the code is considerably more complex than with the previous | |
1803 | example. | |
1804 | ||
4a6725af | 1805 | Secondly, there is a hard-wired limit (in this case 3) to the number of |
d1b91892 AD |
1806 | callbacks that can exist simultaneously. The only way to increase the |
1807 | limit is by modifying the code to add more functions and then | |
54310121 | 1808 | recompiling. None the less, as long as the number of functions is |
d1b91892 AD |
1809 | chosen with some care, it is still a workable solution and in some |
1810 | cases is the only one available. | |
1811 | ||
1812 | To summarize, here are a number of possible methods for you to consider | |
1813 | for storing the mapping between C and the Perl callback | |
1814 | ||
1815 | =over 5 | |
1816 | ||
1817 | =item 1. Ignore the problem - Allow only 1 callback | |
1818 | ||
1819 | For a lot of situations, like interfacing to an error handler, this may | |
1820 | be a perfectly adequate solution. | |
1821 | ||
1822 | =item 2. Create a sequence of callbacks - hard wired limit | |
1823 | ||
1824 | If it is impossible to tell from the parameters passed back from the C | |
1825 | callback what the context is, then you may need to create a sequence of C | |
1826 | callback interface functions, and store pointers to each in an array. | |
1827 | ||
1828 | =item 3. Use a parameter to map to the Perl callback | |
1829 | ||
1830 | A hash is an ideal mechanism to store the mapping between C and Perl. | |
1831 | ||
1832 | =back | |
a0d0e21e | 1833 | |
a0d0e21e LW |
1834 | |
1835 | =head2 Alternate Stack Manipulation | |
1836 | ||
a0d0e21e | 1837 | |
d1b91892 AD |
1838 | Although I have made use of only the C<POP*> macros to access values |
1839 | returned from Perl subroutines, it is also possible to bypass these | |
8e07c86e | 1840 | macros and read the stack using the C<ST> macro (See L<perlxs> for a |
d1b91892 AD |
1841 | full description of the C<ST> macro). |
1842 | ||
1d45ec27 | 1843 | Most of the time the C<POP*> macros should be adequate; the main |
d1b91892 AD |
1844 | problem with them is that they force you to process the returned values |
1845 | in sequence. This may not be the most suitable way to process the | |
1846 | values in some cases. What we want is to be able to access the stack in | |
1847 | a random order. The C<ST> macro as used when coding an XSUB is ideal | |
1848 | for this purpose. | |
1849 | ||
d0554719 | 1850 | The code below is the example given in the section L</Returning a List |
1d45ec27 | 1851 | of Values> recoded to use C<ST> instead of C<POP*>. |
d1b91892 AD |
1852 | |
1853 | static void | |
1854 | call_AddSubtract2(a, b) | |
4358a253 SS |
1855 | int a; |
1856 | int b; | |
d1b91892 | 1857 | { |
4358a253 SS |
1858 | dSP; |
1859 | I32 ax; | |
1860 | int count; | |
d1b91892 | 1861 | |
4358a253 | 1862 | ENTER; |
d1b91892 AD |
1863 | SAVETMPS; |
1864 | ||
4358a253 | 1865 | PUSHMARK(SP); |
d0554719 TC |
1866 | EXTEND(SP, 2); |
1867 | PUSHs(sv_2mortal(newSViv(a))); | |
1868 | PUSHs(sv_2mortal(newSViv(b))); | |
4358a253 | 1869 | PUTBACK; |
d1b91892 | 1870 | |
eb7e169e | 1871 | count = call_pv("AddSubtract", G_LIST); |
d1b91892 | 1872 | |
4358a253 SS |
1873 | SPAGAIN; |
1874 | SP -= count; | |
1875 | ax = (SP - PL_stack_base) + 1; | |
d1b91892 AD |
1876 | |
1877 | if (count != 2) | |
4358a253 | 1878 | croak("Big trouble\n"); |
a0d0e21e | 1879 | |
4358a253 SS |
1880 | printf ("%d + %d = %d\n", a, b, SvIV(ST(0))); |
1881 | printf ("%d - %d = %d\n", a, b, SvIV(ST(1))); | |
d1b91892 | 1882 | |
4358a253 SS |
1883 | PUTBACK; |
1884 | FREETMPS; | |
1885 | LEAVE; | |
d1b91892 AD |
1886 | } |
1887 | ||
1888 | Notes | |
1889 | ||
1890 | =over 5 | |
1891 | ||
1892 | =item 1. | |
1893 | ||
1894 | Notice that it was necessary to define the variable C<ax>. This is | |
1895 | because the C<ST> macro expects it to exist. If we were in an XSUB it | |
1896 | would not be necessary to define C<ax> as it is already defined for | |
1d45ec27 | 1897 | us. |
d1b91892 AD |
1898 | |
1899 | =item 2. | |
1900 | ||
1901 | The code | |
1902 | ||
4358a253 SS |
1903 | SPAGAIN; |
1904 | SP -= count; | |
1905 | ax = (SP - PL_stack_base) + 1; | |
d1b91892 AD |
1906 | |
1907 | sets the stack up so that we can use the C<ST> macro. | |
1908 | ||
1909 | =item 3. | |
1910 | ||
1911 | Unlike the original coding of this example, the returned | |
1912 | values are not accessed in reverse order. So C<ST(0)> refers to the | |
54310121 | 1913 | first value returned by the Perl subroutine and C<ST(count-1)> |
d1b91892 AD |
1914 | refers to the last. |
1915 | ||
1916 | =back | |
a0d0e21e | 1917 | |
02f6dca1 | 1918 | =head2 Creating and Calling an Anonymous Subroutine in C |
8f183262 | 1919 | |
4929bf7b | 1920 | As we've already shown, C<call_sv> can be used to invoke an |
c2611fb3 GS |
1921 | anonymous subroutine. However, our example showed a Perl script |
1922 | invoking an XSUB to perform this operation. Let's see how it can be | |
8f183262 DM |
1923 | done inside our C code: |
1924 | ||
8f183262 DM |
1925 | ... |
1926 | ||
e46aa1dd KW |
1927 | SV *cvrv |
1928 | = eval_pv("sub { | |
1929 | print 'You will not find me cluttering any namespace!' | |
1930 | }", TRUE); | |
8f183262 DM |
1931 | |
1932 | ... | |
1933 | ||
4929bf7b | 1934 | call_sv(cvrv, G_VOID|G_NOARGS); |
8f183262 | 1935 | |
4929bf7b GS |
1936 | C<eval_pv> is used to compile the anonymous subroutine, which |
1937 | will be the return value as well (read more about C<eval_pv> in | |
4a4eefd0 | 1938 | L<perlapi/eval_pv>). Once this code reference is in hand, it |
8f183262 DM |
1939 | can be mixed in with all the previous examples we've shown. |
1940 | ||
9850bf21 RH |
1941 | =head1 LIGHTWEIGHT CALLBACKS |
1942 | ||
1943 | Sometimes you need to invoke the same subroutine repeatedly. | |
1944 | This usually happens with a function that acts on a list of | |
1945 | values, such as Perl's built-in sort(). You can pass a | |
1946 | comparison function to sort(), which will then be invoked | |
1947 | for every pair of values that needs to be compared. The first() | |
1948 | and reduce() functions from L<List::Util> follow a similar | |
1949 | pattern. | |
1950 | ||
1951 | In this case it is possible to speed up the routine (often | |
1952 | quite substantially) by using the lightweight callback API. | |
1953 | The idea is that the calling context only needs to be | |
1954 | created and destroyed once, and the sub can be called | |
1955 | arbitrarily many times in between. | |
1956 | ||
ac036724 | 1957 | It is usual to pass parameters using global variables (typically |
1958 | $_ for one parameter, or $a and $b for two parameters) rather | |
9850bf21 RH |
1959 | than via @_. (It is possible to use the @_ mechanism if you know |
1960 | what you're doing, though there is as yet no supported API for | |
1961 | it. It's also inherently slower.) | |
1962 | ||
1963 | The pattern of macro calls is like this: | |
1964 | ||
82f35e8b | 1965 | dMULTICALL; /* Declare local variables */ |
1c23e2bd | 1966 | U8 gimme = G_SCALAR; /* context of the call: G_SCALAR, |
eb7e169e | 1967 | * G_LIST, or G_VOID */ |
9850bf21 | 1968 | |
82f35e8b RH |
1969 | PUSH_MULTICALL(cv); /* Set up the context for calling cv, |
1970 | and set local vars appropriately */ | |
9850bf21 RH |
1971 | |
1972 | /* loop */ { | |
1973 | /* set the value(s) af your parameter variables */ | |
1974 | MULTICALL; /* Make the actual call */ | |
1975 | } /* end of loop */ | |
1976 | ||
1977 | POP_MULTICALL; /* Tear down the calling context */ | |
1978 | ||
1979 | For some concrete examples, see the implementation of the | |
1980 | first() and reduce() functions of List::Util 1.18. There you | |
1981 | will also find a header file that emulates the multicall API | |
1982 | on older versions of perl. | |
1983 | ||
a0d0e21e LW |
1984 | =head1 SEE ALSO |
1985 | ||
8e07c86e | 1986 | L<perlxs>, L<perlguts>, L<perlembed> |
a0d0e21e LW |
1987 | |
1988 | =head1 AUTHOR | |
1989 | ||
0536e0eb | 1990 | Paul Marquess |
a0d0e21e | 1991 | |
d1b91892 AD |
1992 | Special thanks to the following people who assisted in the creation of |
1993 | the document. | |
a0d0e21e | 1994 | |
c07a80fd | 1995 | Jeff Okamoto, Tim Bunce, Nick Gianniotis, Steve Kelem, Gurusamy Sarathy |
1996 | and Larry Wall. | |
a0d0e21e LW |
1997 | |
1998 | =head1 DATE | |
1999 | ||
d0554719 | 2000 | Last updated for perl 5.23.1. |