Ftdi does not have any way to clone the handle

[tolgadot]

Sorry for rapid fire issues.

Many other similar libraries (like serialport) implement a way to clone or try_clone the handle. This allows one to implement things like two seperate threads, one (blocking on) reading and one writing. I cannot figure out how one would do something like this here.

[newAM]

The libftd2xx FTDI data type is a pointer to a private structure, not a fd. serialport utilizes FDDUPD on Linux, so we can't do the same here: https://docs.rs/serialport/4.2.0/src/serialport/posix/tty.rs.html#335

libftd2xx is also a closed source binary so there is no visibility into the code to know what we can safely do.

[tolgadot]

I experimented with this a bit. Turns out cloning it anyway gives rather undesirable (or undefined?) behavior. I have experimented with giving one instance to one thread which would try to read and the other instance to another thread which would try to write. The operations are not independent of each other. So if one thread blocks waiting for something to read, the other thread cannot write and just keeps waiting until the other thread is done with its read operation. This was observed on Windows.

I do not know if this is an inherent restriction, or something the Ftdi library artificially imposes to ease up its internal workings.

[Farmadupe]

At the signalling level, USB2 is half duplex meaning that devices are physically prevented from transmitting and receiving at the same time. So FTDI would have no reason to implement such an abstraction in their raw C library.

It's almost definitely not difficult to add a small threaded rust wrapper on top of libftd2xx, but I think that's probably best suited to be a base part of some new library that implements concepts like transactions or channels.