What I want is to make sure that nothing in default backend will block application execution, especially callouts.
In that case I'd instead set up a thread farm for running things. (There are a couple of thread farms in different pike modules already. Pike ought to provide a global one that can be used by everyone.)
Also, I want that my application will be scalable in a way that I just can instaniate a copy of some object (which runs entire app) in separate thread, and it won't interfere with anything else (I mean, no lockouts etc)
The only safe way to do that is to run it in a separate process. The basic difference between threads and processes is precisely that the former can interfere with each other in all sorts of ways while the latter basically can't. A separate process will make use of SMP too.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-01 08:13: Subject: Re: Default backend and thread backends?
On Sun, Feb 01, 2004 at 12:05:01AM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
An SMP machine won't be used efficiently anyway because of the interpreter lock.
Does it mean that multithreading in Pike is not effective and should be avoided if possible?
To me it seems a bit odd to have an implicit mapping between threads and backends;
What I want is to make sure that nothing in default backend will block application execution, especially callouts. Sure, I can do everyhing explicitly, but I've no control over external modules, which might be added later.
Also, I want that my application will be scalable in a way that I just can instaniate a copy of some object (which runs entire app) in separate thread, and it won't interfere with anything else (I mean, no lockouts etc) running in another threads (use of SMP would be ideal, but you say that it won't be used efficiently)...
Regards, /Al
/ Brevbäraren