[19095] in s-news-athena
[S] synchronize
daemon@ATHENA.MIT.EDU (Ed Kademan)
Thu Sep 2 08:32:07 1999
To: S News <s-news@wubios.wustl.edu>
From: Ed Kademan <kademan@phz.com>
Date: 02 Sep 1999 08:05:52 -0400
Message-Id: <ulgk8q9plgf.fsf@phz.com>
Yesterday I asked a question about the synchronize function in
Splus3.4 and Bill Dunlap of Mathsoft gave the very thorough and useful
answer reproduced below.
--
Ed Kademan 508.651.3700
PHZ Capital Partners 508.653.1745 (fax)
321 Commonwealth Road <kademan@phz.com>
Wayland, MA 01778
> On 1 Sep 1999, Ed Kademan wrote:
>
> > Can someone explain the following error in more detail?
> >
> > Error in synchronize(1:length(search())): No room in database table
> >
> > This is happening to us with Splus3.4 on Solaris2.6.
> >
> > From within a for-loop we call a function that---among other
> > things---executes the synchronize command mentioned above. The loop
> > bombs out after 2 or 3 iterations. In this particular case we might
> > be able fix things by being more selective in what we synchronize and
> > when, but in general what are the rules governing this "database
> > table?" It seems to me that calling synchronize should just update
> > Splus's notion of which objects are available, it shouldn't cause
> > Splus to use up more room somehow.
>
> In Splus 3.x and 4.x there is a compiled-in limit (50, I think) to the
> number of databases attached. When you attach a database and then
> detach it you use up one entry in the table until the end of the
> top level expression. Calling synchronize(i) implicitly calls detach()
> then attach() so uses up a position in that table. You cannot directly
> look at the database tables but you can see its length by looking at
> unique(storage()$frame)
> All frame numbers less than -2 are frames used for databases in the database
> tables (these frames are used for caching names and objects on the databases).
> You can see the database table fill up with:
>
> > for(i in 1:50){synchronize(1);print(unique(storage()$frame))}
> [1] -13 -12 -11 -10 -9 -8 -7 -6 -5 -4 -3 -2 0 1
> [1] -14 -13 -12 -11 -10 -9 -8 -7 -6 -5 -4 -3 -2 0 1
> [1] -15 -14 -13 -12 -11 -10 -9 -8 -7 -6 -5 -4 -3 -2 0 1
> [1] -16 -15 -14 -13 -12 -11 -10 -9 -8 -7 -6 -5 -4 -3 -2 0 1
> ...
> [1] -51 -50 -49 -48 -47 -46 -45 -44 -43 -42 -41 -40 -39 -38 -37 -36 -35 -34 -33
> [20] -32 -31 -30 -29 -28 -27 -26 -25 -24 -23 -22 -21 -20 -19 -18 -17 -16 -15 -14
> [39] -13 -12 -11 -10 -9 -8 -7 -6 -5 -4 -3 -2 0 1
> [1] -52 -51 -50 -49 -48 -47 -46 -45 -44 -43 -42 -41 -40 -39 -38 -37 -36 -35 -34
> [20] -33 -32 -31 -30 -29 -28 -27 -26 -25 -24 -23 -22 -21 -20 -19 -18 -17 -16 -15
> [39] -14 -13 -12 -11 -10 -9 -8 -7 -6 -5 -4 -3 -2 0 1
> Error in synchronize(1): No room in database table
> Dumped
>
> The rationale for keeping the databases temporarily in the table after
> they were detached was that you be in the middle of executing a function
> from a database when the database is detached and Splus didn't want
> to free the storage used for the function currently being executed.
>
> A workaround in Splus 3.x or 4.x is to use For or a script or program
> to feed commands into Splus as separate top level expressions. Since
> the database table is pruned at the end of the top level expression
> it won't build up. There are lots of other things that build up over
> the course of a top level expressions and feeding things to Splus an
> expression at a time can avoid those bottlenecks as well.
>
> The problem appears to have been fixed in Splus 5.x.
>
> ----------------------------------------------------------------------------
> Bill Dunlap 22461 Mt Vernon-Big Lake Rd
> Data Analysis Products Div. of MathSoft, Inc. Mount Vernon, WA 98274
> bill@statsci.com 360-428-8146
-----------------------------------------------------------------------
This message was distributed by s-news@wubios.wustl.edu. To unsubscribe
send e-mail to s-news-request@wubios.wustl.edu with the BODY of the
message: unsubscribe s-news
