Aha great.
Is 12KB the amount of stack space needed on any x64 platform upon unlimited
use (i.e. whatever size and complexity of SQL queries, whatever dataset/DB
size etc.) with the default configuration/installation?
If not, is there any particular stack size that you would consider a 'safe'
threshold size to stick with? (I ask because we have some dynamic SQL query
generation, where during our testing we might not ourselves have included a
query or dataset/DB of the same size or complexity as a user sometimes would
give rise to.)
I'm in an installation that doesn't necessarily have sparse memory
requirements, it's just that the stack size is fixed and I need to allocate
many of them, so <=100-200KB would be welcome.
Well ultimately I can check based on runtime experience what stack size
sqlite really uses by padding it with 0xsomething and checking at end of
execution how many of them at the end of the stack are still there. The key
criterion is to somehow prove that it'll always be at least one left.
Many thanks,
Mikael
2011/3/29 Richard Hipp <d...@sqlite.org>
> On Mon, Mar 28, 2011 at 5:25 AM, Mikael <mikael....@gmail.com> wrote:
>
> > Hi,
> >
> > I'm looking at the possibility of using SQLite in an environment with a
> > fixed-size stack, and wish to know, what stack size do I need for SQLite
> > always to work?
> >
>
> We have heard of people running SQLite in as little as 2K of stack space.
> Probably there are ways of exceeding that if you really abuse the language,
> but if it works on your tests, SQLite isn't suddenly going to allocate a
> bunch of extra stack on you in the field.
>
> Symbian phones use 12K of stack for SQLite processes.
>
>
> >
> > Obviously I want it to be as small as possible, as I want as much RAM to
> be
> > available for other purposes as possible.
> >
> > The application uses a constant set of SQL queries that are string-exact,
> > except for in the case when in some dynamic queries I pass IN (" in
> > (\"abcd\",\"efghi\",\"jklmn\",\"opqr\"...etc.)"). So the stack size needs
> > to
> > hold for those queries, and any dataset sizes (inserting large cells,
> > querying all of long tables with large cells).
> >
> > If there would be some kind of runtime checks (i.e. the app dies with
> > printing 'Stack overflow' to stderr on stack overflow), I could always
> just
> > increase it up to the level where I ever saw an exception, and add
> another
> > 10% for safety.
> >
> > Looking forward to your response,
> >
> > Kind regards,
> > Mikael
> > _______________________________________________
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >
>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
