I have a c++ program that I have written that opens a USB device and writes to the device. The device that I'm working with is a KVM switch. When I write to the device it switches the monitor/Keyboard/Mouse to a different computer. When I return to this computer the program is still running. But I can't switch again. I've found that if I close the device after the write. I can then reopen the device before the next write and it works.
My question is there anything I can program to handle the fact that the device is removed? I'm not sure the the switch is removed. But the keyboard/monitor/mouse is removed.

You may have to give some more details about how you're writing to it in order to accomplish changing the switch.

My recommendation is to pay attention to what happens to the resources on your system and look at your system log just after you have switched it to another system. And then also what happens when the switch returns to your system, not because you exited and re-entered your program, but because the other computer caused it to switch back. Observe whether or not the resource is re-discovered by your system. Doesn't matter if it is the same resource "name" such as /dev/tty<something>, matters that it was lost and then re-discovered; you can't just keep a handle continually open to it, because the logical connection is lost when the device switches out and is lost in your system.

However you're speaking to that resource, it has either gone away or changed somehow. A thing to do is to persist in trying to speak to it for something like status, or read the version. Once that fails, and it would be "by design" because you've switched it to somewhere else; you should periodically probe for re-discovery of the device. My presumption is that you either manually switch it back or that other computer sends a command to the switch to cause the same result. And then your periodic probe will re-discover the device; whereupon you open it anew, and start talking to it.

So treat it like a two state, state machine. "Searching for a device", "Talking to the device".

When you search and find the device, it's available to you, open it, verify it matches what you expect it to be, and then switch to your "talking to the device" state.

When in the talking state, communicate with it and do your actions as you intend, or don't intend, but periodically verify that you're still able to communicate with the device. If at some point the device becomes unavailable, then you should detect this fact and then switch back to your "searching for a device" state. And I'm saying that by design, when you cause the switch to be available to another computer, it potentially is no longer communicable to your current computer, and therefore a program will be able to detect the loss of the device and make these decisions.

Thanks for the reply.
I think I will look into using the device hot plug events in the libusb-1.0 library. When the device leaves close the file. When the device returns open it back up.
The device that I'm working with is a 4 port KVM switch connecting 4 computers to one monitor/keyboard/mouse.

RAC