indigo icon indicating copy to clipboard operation
indigo copied to clipboard

Support: client vs device context

Open chrsoo opened this issue 5 months ago • 5 comments

Hi,

I am writing a wrapper library for INDIGO as a way of learning Rust and assuming something useful comes out of it, an alternative to C for developing INDIGO clients, servers, and drivers.

Currently I am focusing on adding Rust support for creating remote clients, as this would be my first real world usecase.

As all Rust novices my issues mainly revolve about ownership and borrowing, hence the following question:

  • Who owns the indigo_client->client_context field?

I understand that a client application can stuff any data it desires in the client_context field and INDIGO will leave this untouched. Is this correct?

If correct, this serves me very well as I use the field for linking the INDIGO C-library to my Rust code through an unsafe raw pointer (unsafe from Rust's point of view). The alternative would be to maintain a global state where all clients are registered in a singleton in order to handle the asynchronous callbacks from INDIGO. I way prefer the first option.

I also need to link the devices to my Rust code. Most of the callbacks provide a client parameter that can I could leverage to find the right Rust counterpart, but not so for attach and detach. These two callbacks only have references to the indigo_device struct and I need a way to link them back to my Rust code. Again, I need to either store an unsafe Rust pointer in the indigo_device struct... or use a singleton managing a global list of all devices...

At first I thought I could use the device_context in the same way as the client_ context, but then I realised that this field has its own INDIGO managed struct. Then I tried using private_data until I found that whatever I write to this field is reset each time the callbacks are invoked. Now I understand this field to be owned by the device driver code, so also off-limits.

  • Is there a way to link the device callbacks to my Rust code without resorting to a globally maintained state?

Any feedback or suggestions to the above are welcome!

Assuming I understand things correctly, I think a generic purpose "user" field on indigo_device where I as a downstream INDIGO developer can store a pointer to my own code, would be great. Similar to how I use the client_context to link to my own Rust Client struct. Also, if I am abusing the client_context it would be great with the same field on the indigo_client struct.

/Chris

chrsoo avatar Sep 06 '24 12:09 chrsoo