in reply to Re: Re: Re: Re: Externally managed threads using embedded Perl
in thread Externally managed threads using embedded Perl

I'm sorry, but I am going to have to chicken out here. You are already way beyond anywhere I have ever been or am likely to go:)

You may get lucky and have one of the internals guys pick up on this here, but I would suggest that you try the perl5porters list or comp.lang.perl.something, perhaps misc. Your more likely to encounter people who have been-there-&-done-that there, than you will here.

Maybe merlyn or Abigail-II or one of the other regulars here that also frequent those other haunts can recommend the best place for perl-embedding questions?

About the only one of your questions that I can even attempt an answer at is the "free to wrong pool". Simplistically, this means that something was created by one thread and came up for deletion from another.

This isn't necessarially a programmer error in the sense of the perl code being interpreted containing an error, but often a consequence of a sequence of perl-level program flow that causes an internal inconsistancy that hasn't yet been uncovered. Ithreads are relatively new, and not all the bugs have popped their heads up yet.

That you are doing things rarely done -- embedding -- means you are probably pioneering the use of ithreads in an embedded environment, and are likely to be the finder of such inconsistancies.

About the best advice I can offer is that you go for extreme safety in the first instance. Slow, big and working is better than dying really fast:)

Once you get something working, you can then try slimming it down and speeding it up in small increments, keeping those that work, and baypassing those that don't.

That said, I think I would seriously look at using perl's internal pseudo-fork to do what you are trying to do.

Instantiate a single interpreter, interprete a script that uses everything you need, establishes the connection to the server, and then forks as many copies as you want in your pool.

This will give you the many clones of the environment you set up, each independant from the other, and running in it's own kernel thread within the same process. It would then be up to your C++ code to interface to the clones (I don't knw if this is possible!) and manage them. **THIS IS HIGHLY SPECULATIVE**.

Good luck:)


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Timing (and a little luck) are everything!

  • Comment on Re: Re: Re: Re: Re: Externally managed threads using embedded Perl

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Externally managed threads using embedded Perl
by Anonymous Monk on Jan 09, 2004 at 08:11 UTC

    Where's your sense of commitment! <g>

    Seriously, I'm surprised you stuck with me this long. Thanks very much for all the tips.

    The "make it work, then make it work fast" principle is what I always work with. Just sometimes you can see "obvious" performance hits that you might as well take out while you're doing it in the first place. ::perl_clone vs ::perl_alloc is just such an instance.

    Bad news (for you), I'm going to pick up on your last point. I can easily call a Perl routine always on the *same* thread. How would it then communicate to the thread pool? (See, now look what you've done. I'm starting to learn perl, diving in at the deep end. My wife's not going to be at all happy with you <g>.)

    Phil