Information on SCR# 16 - overlapping reads
Brought to you by:
bwthorp,
rickciervo
Menu
▾
▴
Logged In: YES
user_id=1062933
Info from the developer:
"The logger.dll and the software using it are implemented as
a singled-threaded application. Any IO operation done by a
single-threaded application will block that application
until the IO operation is complete. In the case of the
logger.dll, any read it performs will block the execution of
the application that is using it thus causing that
application to freeze. While the logger.dll is reading, any
input will not be processed. Without the overlapping reads,
clicking on the Cancel button during upload will not work.
With overlapping IO, the logger.dll and application can
continue their execution while waiting for the IO operations
to complete."
Logged In: YES
user_id=1062933
Posted on behalf of a developer using the source code:
"I'm not quite sure of the explanation. I glanced at the
code today and it appeared that the overlapping reads were
not required. In fact, I replaced the overlapping read with
a normal read and the Cancel button still continued to work,
which is what I anticipated.
Now, if someone wanted to have a separate thread reading the
device at the same time the read dialog box is working, that
may create a problem, but only for a single additional
thread...any more than that would still cause issues.
Bottom line, the logger dll is not thread safe...even with
the overlapping reads. Timex would have to make a decision
if they wanted it to be multi-threaded. There are several
options for this (critical sections, C++/OO, etc).
Has Timex discussed a C++ or .NET logger.dll? We already
have a .NET C# layer on top of the logger.dll. It's not
currently multi-threaded, but would be straight-forward to
implement it.
Note: Adding support for interacting with a specific device
(e.g. group upload) would probably require changes that
would support multi-threading.
Food for thought."