This is actually a mistake in documentation. The actual behavior is that
whenever the queue is above the threshold and there isn't already an event
that hasn't been processed by the TSQ callback, it will generate another
event. This was changed because in the other way of implementation, you
would have to check the amount of data in the queue in the TSQ callback to
ensure you read enough to take the queue below the threshold. This would
be more difficult than just reading off the threshold amount and having the
queue post another event if the queue is still above the threshold. Let
me know if you have questions.
Best Regards,
Chris Matthews
Measurement Studio PSE
Scott Dewey wrote:
>Hi,>>In the example BuffNoDataLoss.c, data is written
to the queue in>random
sized blocks ranging from 1 to 500 elements. Simultaneously>data is read
from the queue in a callback function installed via>CmtInstallTSQCallback
in blocks of 50 elements (50 is also the>threshold specified in CmtInstallTSQCallback).
When I read the>documentation, it seems to suggest that the callback function
will>stop being called because quickly there will be more than 50 elements>in
the queue. As I understand it, for the callback function to be>called the
number of elements in the queue must start out below 50 and>then exceed 50.
When I run the project, it continues to call the>callback without fail.
Am I being boneheaded here and missing>something obvious???>>
Thanks,> Scott>-->M. Scott
Dewey Email: msd@rrdjazz.nist.gov>National Institute
of Standards & Technology>Ionizing Radiation Division>100 Bureau Drive, Mail
Stop 8461 Tel: +1 301-975-4843>Gaithers
burg, MD 20899-8461
FAX: +1 301-926-1604
