Re: [sqlite] Re: Question about multithreading
Gil: In you threads, dont declare sqlite3 *db private or public, instead make it a local variable in each method. Then if one class calls a method from another, a seperate database pointer will exist (on each threads local stack) and you will have no problems. Let me know how it works. -- Rich Rich, So you mean I should open/close a sqlite database locally on methods that can be called by several threads, instead of using a global pointer? That would makes sense to me. Thanks! - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Re: Question about multithreading
On 3/22/07, Igor Tandetnik <[EMAIL PROTECTED]> wrote:
Gil Delavous <[EMAIL PROTECTED]>
wrote:
> However, what happens when a thread calls a method from the main
> thread, this one using its own sqlite connection?
The question doesn't make any sense to me, sorry. Methods don't belong
to threads. Any function in a program can, in principle, be executed by
any thread at any time, including by multiple threads simultaneously.
> For example:
>
> Main thread:
> void main::query_something() {
> // query something using main thread's sqlite connection
> }
>
> Print thread:
> void print::print_result() {
> int value = main->query_something();
> }
What makes you think these classes are somehow affine to a particular
thread? They are not. When you call query_something from print_result,
the same thread that executed print_result now executes query_something,
whether it's a "main" thread (whatever that means) or otherwise.
If it's your intention that all methods from class main be called on one
thread, and all methods of print be called on another, it's up to your
program to ensure that. You need some kind of inter-thread communication
mechanism, e.g. a producer/consumer queue.
> As my main thread has tons of utility methods called from other
> threads
You seem to say "thread" when you mean "class", and this lies at the
heart of your confusion. Realize that the two are entirely different,
largely unrelated concepts.
Igor Tandetnik
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Gil:
In you threads, dont declare sqlite3 *db private or public, instead
make it a local variable in each method. Then if one class calls a
method from another, a seperate database pointer will exist (on each
threads local stack) and you will have no problems. Let me know how
it works.
--
Rich
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: SPAM: [sqlite] Re: Question about multithreading
Hi Igor,
Thanks for you reply. I might have confused things, sorry about that.
So, from my example, let say thread A created the object "main", and
thread B created the object "print".
When thread B calls the method from object "main" (as shown by the
example), my question was to know if the sqlite connection opened by
object "main" can be considered as shared with thread B, much like if I
used this connection pointer directly from thread B?
Gil
Le Thu, 22 Mar 2007 12:53:57 +0100, Igor Tandetnik <[EMAIL PROTECTED]> a
écrit:
Gil Delavous <[EMAIL PROTECTED]>
wrote:
However, what happens when a thread calls a method from the main
thread, this one using its own sqlite connection?
The question doesn't make any sense to me, sorry. Methods don't belong
to threads. Any function in a program can, in principle, be executed by
any thread at any time, including by multiple threads simultaneously.
For example:
Main thread:
void main::query_something() {
// query something using main thread's sqlite connection
}
Print thread:
void print::print_result() {
int value = main->query_something();
}
What makes you think these classes are somehow affine to a particular
thread? They are not. When you call query_something from print_result,
the same thread that executed print_result now executes query_something,
whether it's a "main" thread (whatever that means) or otherwise.
If it's your intention that all methods from class main be called on one
thread, and all methods of print be called on another, it's up to your
program to ensure that. You need some kind of inter-thread communication
mechanism, e.g. a producer/consumer queue.
As my main thread has tons of utility methods called from other
threads
You seem to say "thread" when you mean "class", and this lies at the
heart of your confusion. Realize that the two are entirely different,
largely unrelated concepts.
Igor Tandetnik
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
[sqlite] Re: Question about multithreading
Gil Delavous <[EMAIL PROTECTED]>
wrote:
However, what happens when a thread calls a method from the main
thread, this one using its own sqlite connection?
The question doesn't make any sense to me, sorry. Methods don't belong
to threads. Any function in a program can, in principle, be executed by
any thread at any time, including by multiple threads simultaneously.
For example:
Main thread:
void main::query_something() {
// query something using main thread's sqlite connection
}
Print thread:
void print::print_result() {
int value = main->query_something();
}
What makes you think these classes are somehow affine to a particular
thread? They are not. When you call query_something from print_result,
the same thread that executed print_result now executes query_something,
whether it's a "main" thread (whatever that means) or otherwise.
If it's your intention that all methods from class main be called on one
thread, and all methods of print be called on another, it's up to your
program to ensure that. You need some kind of inter-thread communication
mechanism, e.g. a producer/consumer queue.
As my main thread has tons of utility methods called from other
threads
You seem to say "thread" when you mean "class", and this lies at the
heart of your confusion. Realize that the two are entirely different,
largely unrelated concepts.
Igor Tandetnik
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
