On Wed, Nov 22, 2000 at 12:29:55PM -0500, Dan Sugalski wrote: > At 09:17 AM 11/22/00 -0800, Dave Storrs wrote: > > > >On Tue, 21 Nov 2000, Jarkko Hietaniemi wrote: > > > > > Yet another bummer of the current SVs is that they poorly fit into > > > 'foreign memory' situations where the buffer is managed by something > > > else than Perl. "No, thank you, Perl, keep your greedy fingers off > > > this chunk. No, you may not play with it." > > > > > > Out of curiousity, when might such a situation arise? When you > >are embedding C in Perl, perhaps? > > More often vice versa. INN embeds perl, for example, and uses it for spam > detection. When it builds scalars for perl to use, it uses the copy of the > article already in memory to avoid copies. (Given the volume of news and > the size of some news articles this can save a lot) You wouldn't want perl > messing with it in that case, since the string memory really isn't perl's > to manage. One can imagine having per a foreign block of memory a table of function pointers from Perl to the foreign application, for example (void *)(*foreign_realloc)(void*,size_t) for Perl to beg for more memory, and void(*foreign_free)(void*) to tell that Perl doesn't care about that block any more, and so on, but the foreign app is of course free to ignore such requests. "Who is this Perl guy, anyway?" -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
