view tests/0033/run-test.sh @ 400:8c7453fb5bd9 api-inversion

Invert audioDB::power_flag / audiodb_power()

Here the exciting discovery is that the mmap(), memcpy(), munmap()
sequence is in fact not safe.  In principle an msync() call should be
inserted before unmapping for in-core changes to mmap()ed files to be
flushed to disk.

In this case we work around the problem entirely, by not mmap()ing
anything and doing everything with file descriptors.  Amusingly, that's
probably not desperately safe either, this time because we have to move
the file descriptor position (which is also a shared resource).  dup()
doesn't save us, as the duplicate file descriptor shares a file
position.

This applies also to the filling of data_buffer in the query loop, and
in fact basically any call to lseek(), which is why I'm not fixing it
now.  Solution: if you have multiple threads all acting at once on a
single database, do one audiodb_open() per thread, for now at least.

#! /bin/bash

. ../test-utils.sh

if [ -f testdb ]; then rm -f testdb; fi

${AUDIODB} -d testdb -N

intstring 2 > testfeature01
floatstring 0 1 >> testfeature01
intstring 2 > testfeature10
floatstring 1 0 >> testfeature10

${AUDIODB} -d testdb -I -f testfeature01
${AUDIODB} -d testdb -I -f testfeature10

# sequence queries require L2NORM
${AUDIODB} -d testdb -L

echo "query point (0.0,0.5)"
intstring 2 > testquery
floatstring 0 0.5 >> testquery

${AUDIODB} -d testdb -Q sequence -l 1 -f testquery -R 5 > testoutput
echo testfeature01 1 > test-expected-output
echo testfeature10 1 >> test-expected-output
cmp testoutput test-expected-output
${AUDIODB} -d testdb -Q sequence -l 1 -f testquery -K /dev/null -R 5 > testoutput
cat /dev/null > test-expected-output
cmp testoutput test-expected-output

echo testfeature01 > testkl.txt
${AUDIODB} -d testdb -Q sequence -l 1 -f testquery -K testkl.txt -R 5 > testoutput
echo testfeature01 1 > test-expected-output
cmp testoutput test-expected-output
echo testfeature10 > testkl.txt
${AUDIODB} -d testdb -Q sequence -l 1 -f testquery -K testkl.txt -R 5 > testoutput
echo testfeature10 1 > test-expected-output
cmp testoutput test-expected-output

echo testfeature10 > testkl.txt
${AUDIODB} -d testdb -Q sequence -l 1 -f testquery -K testkl.txt -r 1 -R 5 > testoutput
echo testfeature10 1 > test-expected-output
cmp testoutput test-expected-output

# NB: one might be tempted to insert a test here for having both keys
# in the keylist, but in non-database order, and then checking that
# the result list is also in that non-database order.  I think that
# would be misguided, as the efficient way of dealing with such a
# keylist is to advance as-sequentially-as-possible through the
# database; it just so happens that our current implementation is not
# so smart.

echo "query point (0.5,0.0)"
intstring 2 > testquery
floatstring 0.5 0 >> testquery

${AUDIODB} -d testdb -Q sequence -l 1 -f testquery -R 5 > testoutput
echo testfeature01 1 > test-expected-output
echo testfeature10 1 >> test-expected-output
cmp testoutput test-expected-output

echo testfeature10 > testkl.txt
${AUDIODB} -d testdb -Q sequence -l 1 -f testquery -K testkl.txt -r 1 -R 5 > testoutput
echo testfeature10 1 > test-expected-output
cmp testoutput test-expected-output

exit 104