Retention of serial port's open/close state

  • Thread starter Thread starter Richard Kucia
  • Start date Start date
R

Richard Kucia

I have a little port tester app that lets me open/close/read/write the COM1:
port. Under normal circumstances, the app works fine. However, if I open the
port and then exit the program without closing the port, it seems to me that
the port is still open. I know this because if I rerun the program, it is
unable to open the port. A soft-reset is required to free the port (and that
leads to another problem; see my other post on this date).

Is there a workaround that will force the port to close when the program
terminates? Thanks.

Richard Kucia
 
Wrap the port code in an IDisposable object and have the Dispose method
close the port handle. In your apps shutdown routine, dispose the object.
 
Chris,

That's what I decided to do. It just seemed odd to me that I needed to close
a file handle -- I thought that was automatic. Thanks for replying.

Rick
 
The close is automatic when the handle's owner is destroyed. The problem
you're seeing is that the handle is owned by an object that doesn't actually
die until the GC grabs it, which may actually be some time after the app
ends. By marking the object as disposable and explicitly disposing it, you
increase the timeliness of that collection.
 
The issue is that the objects are created in a managed environment. One
would assume that when the app ends, all of the objects associated with the
app would get cleaned up, but as you have discovered this isn't the case.
My thoughts are that either A) The objects remain in memory until the GC
does a collection cycle based on its own criteria (which I've seen take
several minutes in low activity, high-available memory situations) or B) The
handle you have is not properly disposed by it's parent object so that it
remains valid, yet orphaned. In either case, manually disposing of it
workes around the problem.
 
Back
Top