On Mon, Oct 8, 2012 at 2:46 AM, Staffan Tylen <staffan.ty...@gmail.com> wrote:
> 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. Well, under 64-bit Windows the number of threads you could start would probably increase by a thousand or more. > 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? ooSQLite does not do any additional locking. > Regardless of this, I may look at reducing the number of threads that are > created by placing a depth limit for child expansion. Well, I think the final decision should be made after testing your program. If creating thousands of threads seems to work, then okay. -- 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
