Re: threads: spawn early to avoid the crush.

It's a funny coincidence (but I'm not laughing yet), that I saw this post at the end of a day where I learned that I may need to switch from perl built without threads to perl built with threads, in order to get DBD::Oracle to work (cf. DBD::Oracle and threading on a web server).

So your findings about runtime and memory usage led me to ponder how likely it would be that some simple-minded perl script using DBI to do stuff with data from Oracle tables might get kind of ugly, just because a simple-minded perl hacker doesn't know about, think about, or have a choice regarding the kind of coding adjustment you demonstrated in your benchmarks.

For example, someone decides to load a lot of data from a file before connecting to the database -- and then DBD::Oracle starts doing stuff with threads "under the table", completely unbeknownst to the hapless programmer. (Maybe DBD::Oracle doesn't really do stuff with threads, but then I don't understand why it seems to need thread support...)

Anyway, part of what you're hoping for seems unattainable, unless you accept a trade-off: you can economize on memory and runtime if you can specify up front exactly how many threads you intend to use. That's great, but isn't there a whole class of apps whose defining trait is the ability to start new threads on an as-needed basis (not knowing in advance how many will be needed)?

I am not someone who can go into detail on this, but roughly speaking, it sounds like what is needed is a way to define some sort of initial minimal state -- like a snapshot at startup -- such that each new thread starts out with just the minimal stuff defined therein; the parent process might know of specific data that a given thread would need, and would explicitly enable the access (whether copied or shared), but without this action from the parent, the thread must simply accumulate its own data separately.

I don't have a clue how that would be implemented (for all I know, it might already be implemented!) -- but just in conceptual terms, that seems like what you'd want.

Comment on Re: threads: spawn early to avoid the crush.

Replies are listed 'Best First'.
Re^2: threads: spawn early to avoid the crush. by BrowserUk (Patriarch) on Mar 03, 2006 at 05:10 UTC
As I've, (I hope correctly), explained in the other thread, but I'll summaries here also to assuage any fears, threads created by call C APIs (pthreads_create()/CreateThread()/_beginThread()/other) will be completely unaffected by any memory considerations associated with Perl's cloning of Perl data. They would possibly be affected by the changes to process stacksize settings as I described in another recent thread--if they choose to use implicit stack size settings, but that's less common in C/C++ as the have access to the calls/parameters to use explicit values. Anyway, part of what you're hoping for seems unattainable, unless you accept a trade-off: you can economize on memory and runtime if you can specify up front exactly how many threads you intend to use. That's great, but isn't there a whole class of apps whose defining trait is the ability to start new threads on an as-needed basis (not knowing in advance how many will be needed)? Yes. That is the problem in a nutshell. Creating a "factory thread" very early in the script before anything else heavy is loaded is relatively easy to do. Even passing coderefs (which are allocated on the heap and (I believe) threadsafe), to the that thread factory so that it can spawn the new thread from a lightweight environment should be possible. The real problem comes in transferring context, and parameters, and retrieving results. I'm convinced it is possible, I just haven't put the right set on incantations together yet. At least, I hope that is the problem. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]

Replies are listed 'Best First'.

Re^2: threads: spawn early to avoid the crush.
by BrowserUk (Patriarch) on Mar 03, 2006 at 05:10 UTC

As I've, (I hope correctly), explained in the other thread, but I'll summaries here also to assuage any fears, threads created by call C APIs (pthreads_create()/CreateThread()/_beginThread()/other) will be completely unaffected by any memory considerations associated with Perl's cloning of Perl data.

They would possibly be affected by the changes to process stacksize settings as I described in another recent thread--if they choose to use implicit stack size settings, but that's less common in C/C++ as the have access to the calls/parameters to use explicit values.

Anyway, part of what you're hoping for seems unattainable, unless you accept a trade-off: you can economize on memory and runtime if you can specify up front exactly how many threads you intend to use. That's great, but isn't there a whole class of apps whose defining trait is the ability to start new threads on an as-needed basis (not knowing in advance how many will be needed)?

Yes. That is the problem in a nutshell. Creating a "factory thread" very early in the script before anything else heavy is loaded is relatively easy to do. Even passing coderefs (which are allocated on the heap and (I believe) threadsafe), to the that thread factory so that it can spawn the new thread from a lightweight environment should be possible. The real problem comes in transferring context, and parameters, and retrieving results.

I'm convinced it is possible, I just haven't put the right set on incantations together yet. At least, I hope that is the problem.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]