Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Opening multiple file handles to single hardware
16 views
Skip to first unread message
af30...@gmail.com
Apr 15, 2013, 11:05:55 AM4/15/13
to
Hi all,
I'm not sure how to work around an issue that I'm seeing on Linux. I have a library that will make use of a single piece of USB hardware. In order to talk with it, I'm using the HID API (http://www.signal11.us/oss/hidapi/) which sits on top of libusb.
The hardware has multiple "channels" on it. Communication with the hardware is supposed to be done using bitfields. One doesn't open a handle to the individual "channels" but instead to the entire device. Instructing which channel performs whatever task is done through toggling the appropriate bits. The problem that I'm having is that each time a thread or process opens another handle to the hardware, the previous handle becomes unusable. In Windows this is accomplished by opening shared file handles. However, and I wished my Linux weren't so rusty, apparently shared file handles aren't done the same way (if at all) in Linux/UNIX.
What must I do in order to share access to this hardware across threads and processes (perhaps even share access within the same thread)?
Thanks,
Andy
I'm not sure how to work around an issue that I'm seeing on Linux. I have a library that will make use of a single piece of USB hardware. In order to talk with it, I'm using the HID API (http://www.signal11.us/oss/hidapi/) which sits on top of libusb.
The hardware has multiple "channels" on it. Communication with the hardware is supposed to be done using bitfields. One doesn't open a handle to the individual "channels" but instead to the entire device. Instructing which channel performs whatever task is done through toggling the appropriate bits. The problem that I'm having is that each time a thread or process opens another handle to the hardware, the previous handle becomes unusable. In Windows this is accomplished by opening shared file handles. However, and I wished my Linux weren't so rusty, apparently shared file handles aren't done the same way (if at all) in Linux/UNIX.
What must I do in order to share access to this hardware across threads and processes (perhaps even share access within the same thread)?
Thanks,
Andy
Jorgen Grahn
Apr 15, 2013, 2:41:50 PM4/15/13
to
which acts as the middleman, and makes sure only one copy of itself is
running.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Barry Margolin
Apr 15, 2013, 5:21:28 PM4/15/13
to
In article <slrnkmoife.3...@frailea.sa.invalid>,
And you could interface with the daemon using a FUSE filesystem.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Jorgen Grahn
Apr 15, 2013, 6:56:30 PM4/15/13
to
On Mon, 2013-04-15, Barry Margolin wrote:
> In article <slrnkmoife.3...@frailea.sa.invalid>,
> Jorgen Grahn <grahn...@snipabacken.se> wrote:
>
>> On Mon, 2013-04-15, af30...@gmail.com wrote:
...
> In article <slrnkmoife.3...@frailea.sa.invalid>,
> Jorgen Grahn <grahn...@snipabacken.se> wrote:
>
>> On Mon, 2013-04-15, af30...@gmail.com wrote:
>> > What must I do in order to share access to this hardware across
>> > threads and processes (perhaps even share access within the same
>> > thread)?
>>
>> I don't know the area, but one obvious way is by writing a daemon
>> which acts as the middleman, and makes sure only one copy of itself is
>> running.
>
> And you could interface with the daemon using a FUSE filesystem.
Or Unix domain sockets, or whatever. Hard to tell what's best without
>> > threads and processes (perhaps even share access within the same
>> > thread)?
>>
>> I don't know the area, but one obvious way is by writing a daemon
>> which acts as the middleman, and makes sure only one copy of itself is
>> running.
>
> And you could interface with the daemon using a FUSE filesystem.
knowing how the product works and what the software should do.
0 new messages