libusb и асинхронные операции Опции

[SM]

Такой вопрос. Как я понимаю, для булок в либусб есть только вот это:

int usb_bulk_read(usb_dev_handle *dev, int ep, char *bytes, int size, int timeout);

А я хочу сделать большой и длинный write, и в параллель ему пустить большой и длинный read (на каждые два полученных слов девайс отдает одно обратно). И что делать? Вижу два выхода. Первый - в одном треде дать write, в другом read. А как оно, жить-то будет? либусб нормально мультитредность переносит? Второй... Пока не вижу... Есть ли в либусб асинхронные операции ? И какие есть альтернативы либусб вообще?

[Harbour]

Так можно - главное чтобы libtclxds.so не содержала в себе libusb ни в каком виде, токмо как в dynamic linked, неважно через какие промежуточные либы. А то что Freeware или ХренWare - если недоступны исходники, то уже нарушаем LGPL.

А гембель в том, что никто модуль этот собирать сам не будет, по причине того что binutils/gcc/kernel headers мало у кого стоит - и придется или как у Nvidi'и иметь херову тучу уже собранных или писать инсталлятор. тут наступаем на новые грабли, так как у юзеров N^N вариантов конфигурирования ядра, X^Y вариантов binutils/gcc - будут присылать неудачные логи, придется их разгребать и решать одни и те же вопросы, которые давно описаны в факе, который, в свою очередь никто не читает ... и все это на расплодившемся множестве дистров ... вобщем волосы дыбом на одном месте обеспечены.

То ли дело бинарная libusb - кинул и забыл

[al333]

А гембель в том, что никто модуль этот собирать сам не будет, по причине того что binutils/gcc/kernel headers мало у кого стоит - и придется или как у Nvidi'и иметь херову тучу уже собранных или писать инсталлятор. тут наступаем на новые грабли, так как у юзеров N^N вариантов конфигурирования ядра, X^Y вариантов binutils/gcc - будут присылать неудачные логи, придется их разгребать и решать одни и те же вопросы, которые давно описаны в факе, который, в свою очередь никто не читает ... и все это на расплодившемся множестве дистров ... вобщем волосы дыбом на одном месте обеспечены.

То ли дело бинарная libusb - кинул и забыл

Если дело касается "крутых" убунтоидов, то возможно headers нет, а так Nvidia со своего сайта выдает sh-скрипт в котором и открытые исходники и уже собранные. Главное прописать зависимости. Ну и для каждой версии ядра придется проверять.
И поэтому,на мой взгляд, если в твоей закрытой проге супер навороченные функции, то лучше модуль. Ну, а если тебя устраивают libusb-функции, то лучше libusb. Статически слинкованный тоже обращается в конечном итоге к ядру, поэтому уж лучше модуль.