Does ets:select/2 block the VM?

[Shawn Pearce]

Ok, I just read the ets:safe_fixtable/2 docs:

	Note that no deleted objects are actually removed from a fixed table
	until it has been released. If a process fixes a table but never
	releases it, the memory used by the deleted objects will never be
	freed. The performance of operations on the table will also degrade
	significantly.

	Use info/2 to retrieve information about which processes have
	fixed which tables. A system with a lot of processes fixing
	tables may need a monitor which sends alarms when tables have
	been fixed for too long.

The implied meaning behind these kind of worries me a little.  :-)
It seems like the table can be modified while other proccesses have
outstanding fixtable requests (traversing), but that objects which
are deleted won't get deleted until all fixtable requests are released.
What happens if this never occurs because a process is always fixtable'd?
(A fixtables, B fixtables, A releases, A fixtables, B releases...)
What assurances are made that the table is timely GC'd after all fixtable's
have been removed?

I may be in a situation of a "system with a lot of processes fixing tables".
Or at least something like that.  It all depends, I have a single operation
that requires me to scan a group of ets tables when a process/connection starts
up, but after that I should rarely, if ever scan the ets tables again.  Problem
is, I don't know what my connection rate is yet.  I'm assuming it'll be
something like hundreds of connections in a 15 minute window in the morning as
people sign on to the system when they arrive at work, and then almost no
activity for the rest of the day.

I'm just wondering if I may run into trouble with this by having hundreds of
processes scanning the ets tables around the same time or not.  Must test this
soon I guess.



Shawn Pearce <spearce@REDACTED> wrote:
> Bjorn Gustavsson <bjorn@REDACTED> wrote:
> > > Also, the documentation is vague as to what happens if the table owner
> > > modifies a protected ets table using insert or delete while other
> > > processes are using ets:select/2 or ets:select/3 (select with
> > > a limit and continuation).  Is it safe to perform this, or does
> > > the reader process have to use ets:safe_fixtable/2 ?
> > Sorry for the vague documentation. What should have been in the doc is
> > this:
> > 
> > It is "safe" to use select/2 (or match/match_object) on a table while
> > another process is updating it. It will however not be a real transaction.
> > The table is fixed during the select-operation, but if an object appears
> > in the table it depends on the hash value (in the set/bag/duplicate bag
> > case) if the simultaneous select will see it, i.e. if the select has
> > already traversed the hash bucket where the new object is inserted, it
> > wont see it and vice versa. In the ordered set case, the effect is rougly
> > the same, but it depends on the key value itselt if it will be seen (the
> > order).
> > 
> > In the case of select/3, the "automatic fixation" of the table cannot be
> > done (cause ets does not know when you're done traversing), so you have to
> > use safe_fixtable/2 to achieve the same effect. If you use ordered_set,
> > the safe_fixtable/2 is a noop however, it simply isn't needed for trees,
> > so strictly speeking it isn't really needed for that table type, but it
> > costs very little to use it anyway.
> 
> 
> I recently switched to select/3, so this is good to know (that I must
> safe_fixtable/2 before and after).  Thanks.

-- 
Shawn.

  Today is the last day of your life so far.