Prev: Can't exit parfor loop! Please help!!!!
Next: Initial/final values in solving Riccati equation
From: Mark on 2 May 2010 06:22
Is it possible to abort writing to a USB port using fwrite from a GUI, so without ctrl+c?
From: Walter Roberson on 2 May 2010 19:08
Mark wrote:
> Is it possible to abort writing to a USB port using fwrite from a GUI,
> so without ctrl+c?

There are three possibilities here:

1) the program issued the write request so recently that the operating
system has not had time to enter the request into its internal queues.
Signals such as those initiated by control-C _are_ permitted to abort
the write request in such a case.

2) the program has issued the write request and the operating system has
entered it into its internal queue, but the transfer of that block of
data to the device has not yet begun. In such a situation, although it
is allowed under the international standards to dequeue the transfer
before it has started, the way that operating systems are designed in
practice makes it _effectively_ impossible to cancel the request without
aborting the program completely (i.e., kill Matlab, not just the
function Matlab is proessing), unless the device returns an error status
(e.g., the USB device was unplugged.)

3) the transfer of the data has actually begun but is not yet complete.
In such a situation, the international standards do not allow the
transfer to be terminated unless the device returns an error status or
the system is rebooted.

The above discussion assumes that you are using standard fwrite() calls
and that the device has not been opened with special flags indicating
that asynchronous operations are permitted. When I speak of asynchronous
operations in this context, I am not referring to the link-level
transfer of data being slaved to a clock (synchronous transfer) or not
(asynchronous transfer), but rather to whether the operating system must
wait for the I/O to complete (or fail) before allowing the program
(synchronous I/O *requests*) or if instead the operating system is
permitted to allow the program to resume before the I/O is complete,
risking the possibility that when it is time for the I/O to actually
take place that the I/O might fail and the program might be notified of
that fact at a later time when it is involved in a completely different
logical phase of the program (asynchronous I/O *requests*.) Matlab is
not designed to handle asynchronous I/O *requests*, but of course Matlab
cannot prevent the user from MEX'ing up something that causes
asynchronous I/O *requests* to be processed.


To restate to (hopefully) enhance clarity: a synchronous I/O *request*
is one in which the return value from the I/O call tells you whether the
I/O worked and how much data was really transferred -- and this is the
case no matter how the link-layer physically transfers the data. The
request and the return status are synchronized. This style of I/O is
used for pretty much everything except very high performance tuned
systems (e.g., commercial multi-user databases such as banking systems),
but the cost of the simplicity of the operations is that it is quite
difficult to "nicely" cancel a read or write request that has not yet
been submitted to a device, and it is a violation of international
standards to cancel these kind of read of write requests if the data has
already been partly transfered.

An asynchronous I/O *request* is one in which the program is allowed to
resume execution and is told the result of the I/O at some later point.
It is much easier to cancel an asynchronous I/O request if it has not
yet started at the device level; I do not recall at the moment what the
international standards say about canceling these kinds of requests
while the data is is in mid-transfer. Matlab does not (to my knowledge)
provide any support for asynchronous I/O requests.
 | 
Pages: 1
Prev: Can't exit parfor loop! Please help!!!!
Next: Initial/final values in solving Riccati equation