Project

General

Profile

Feature #4915

consider a one-thread-per-line architecture

Added by laforge 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
12/18/2020
Due date:
% Done:

0%

Spec Reference:

Description

If we want to auto-discover hot-plugged USB devices at runtime, we need to consider situations where we hve to do that while other E1 interfaces/lines are in operation. We hence have to do everything asynchronous/non-blocking to those existing interfaces/lines.

This is particularly cumbersome in terms of anything that performs USB transactions to the new device:
  • obtaining the serial number string of the USB device
  • SET_CONFIGURATION
  • SET_INTERFACE (needed for altif=1)

One approach would be to have one thread per e1_line. This thread would be created before opening the respective USB device (each in its own libusb_context). It would furthermore server all the per-timeslot file-descriptors of the line it serves, and due to its own libusb_context also serve [only] those libusb file-descriptors related to its USB interface.

We'd need some rwlock around the global list of interfaces / devices (vty introspection from main thread), and some kind of fd-based communication between main thread (ctl socket from/to applications) and the per-line threads for handling TS_OPEN / LINE_CONFIG.

This architecture would give us the least possible impact from opening a new USB interface (== e1_line) and provide significant isolation.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)