| Author |
Message |
|
| rjmh |
 Posted: Wed Jun 30, 2010 5:02 pm |
 |
|
|
User
Joined: 16 Nov 2008
Posts: 18
|
I'm playing with dets and QuickCheck, and have encountered behaviour that seems strange to me--although I'm not entirely clear on how dets is supposed to behave if the table is modified during a traversal, so I can't say for certain that this is a bug.
Basically, I'm doing a lazy traversal of the table using match_object, and I'm finding that one of the objects in the table is being returned TWICE. To provoke that, I need to do two things:
a.. insert an element with the same key (after starting the traversal)
b.. do an apparently unrelated traversal of the table
I've translated the QuickCheck counterexample into a unit test---which passes---so you can see the weirdness just by reading the code. Here's the test:
test() ->
% The file dets_table does not exist when we start the test
dets:open_file(dets_table,[{type,bag}]),
% Insert some data... note, 3 objects in the table, our match will
% traverse 2 objects at a time.
dets:insert(dets_table,[{0,0},{1,0},{2,3}]),
% Fix the table before starting a match_object traversal. Note that
% the behaviour is the same whether or not we do this--it's included
% to show that the problem is not that I failed to fix the table!
dets:safe_fixtable(dets_table,true),
% Start the traversal, returning the first two objects.
{[{1,0},{2,3}],Cont} = dets:match_object(dets_table,{'$1','$2'},2),
% Add another object DURING THE TRAVERSAL. Important that it has
% the SAME KEY as the object not yet traversed.
dets:insert(dets_table,[{0,1}]),
% Perform an apparently unrelated traversal of the table.
[] = dets:match_object(dets_table,{2,2}),
% Continue the original traversal.
% WHAT??? How come we get {0,0} twice???
{[{0,0},{0,0},{0,1}],_} = dets:match_object(Cont),
ok.
The insertion and unrelated traversal can also be performed in another process--it makes no difference, the funny behaviour still occurs.
Is this a bug?
John
Post received from mailinglist |
|
|
| Back to top |
 
|
| Hans Bolinder |
| Posted: Thu Jul 01, 2010 8:29 am |
|
|
|
User
Joined: 05 Nov 2008
Posts: 24
Location: Stockholm
|
[John Hughes:]
> I'm playing with dets and QuickCheck, and have encountered behaviour
> that seems strange to me--although I'm not entirely clear on how
> dets is supposed to behave if the table is modified during a
> traversal, so I can't say for certain that this is a bug.
It's a short-coming of Dets. There is a note about it in dets(3),
safe_fixtable/2:
It is not guaranteed that calls to first/1, next/2, select and
match functions work as expected even if the table has been fixed;
the limited support for concurrency implemented in Ets has not yet
been implemented in Dets. Fixing a table currently only disables
resizing of the hash list of the table.
Best regards,
Hans Bolinder, Erlang/OTP team, Ericsson
________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-bugs-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
