Thanks for the comments. Some background information: I'm using
multi-threading to populate a tree view. For this I've implemented a
context menu with an Expand-All option. When used and I find a child that
hasn't been expanded yet (sounds horrible in a different context!), I start
a new thread to perform the expansion using SQLite data. That thread may in
turn spawn new threads, etc. This can easily reach thousands of threads, so
I definitely believe that I've hit the limit of 2048.
Regarding SQLite, I'm of the impression that SQLite sets SHARED locking for
serialization of read requests, so any number of threads should be able to
read from the database at the same time. (
http://www.sqlite.org/lockingv3.html). The locking mechanism is from what I
understand automatic and beyond the programmer's control (with the
exception of shared-cache mode, which is not applicable in this case). I
don't know if ooSQLite may be doing some locking of its own that may
prevent the effects of SHARED locking, does it?
Regardless of this, I may look at reducing the number of threads that are
created by placing a depth limit for child expansion.
Staffan
On Mon, Oct 8, 2012 at 5:27 AM, Mark Miesfeld <miesf...@gmail.com> wrote:
> On Sun, Oct 7, 2012 at 3:47 PM, Staffan Tylen <staffan.ty...@gmail.com>
> wrote:
>
> > Thanks, I suspected that. At some point I will install the 64bit
> versions of
> > the components that I'm currently using and see how that goes. Will
> provide
> > feedback.
>
> The theoretical per-process thread limit on 32-bit Windows is 2048.
> But typically you would run into a memory limit before you hit that.
> Around 2020 is more likely.
>
> The theoretical limit on 64-bit Windows is larger, but again you're
> more likely to run into a memory limitation before you hit the thread
> count limit. Since I don't think you started 2020 threads, going to
> 64-bit Windows is not going to change anything for you.
>
> Trying to create so many threads in ooRexx is more likely to bog your
> program down than be of any real use. Especially since I believe you
> are using both ooSQLite and ooDialog.
>
> SQLite is *safe* to run in multiple threads, but access to a single
> database is serialized. Access to the database is not concurrent.
> Each access to the database must wait until it holds the single
> database mutex, It then holds the mutex until it finishes what it is
> doing and then gives up the mutex for the next access to use.
>
> In ooDialog, much of what is done involving the dialog and the dialog
> controls takes place in the window message processing loop of the
> dialog. This runs on a single thread, that's the way Windows works.
> In addition, each call in the C / C++ implementation code that calls
> back into the interpreter needs to obtain the kernel lock before it
> executes.
>
> This works extremely well for a small number of threads.
>
> But if you start a large number of threads within the same dialog
> class, experience has shown me that it just slows things down.
>
> Unless your threads are doing a lot of processing that does not
> involve any method invocations of any objects in either the ooSQLite
> framework or the ooDialog framework, you might want to rethink
> starting a lot of threads. Actually, for ooSQLite, different threads
> might help, *if* there are different individual databases involved,
>
> --
> Mark Miesfeld
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Oorexx-users mailing list
> Oorexx-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-users
>
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
