So I'm working on a growing C program in a Linux / POSIX environment, and I've run into an area where I'm not quite sure how to proceed.

Basically, I'm using a module pattern to develop my code for use with different external hardware and I/O operations (for example: a file module, a camera module, a Serial module, etc.) Some of these operations take a bit of time to complete, and should be placed in their own thread for obvious reasons.

My question basically boils down to this: Should the modules themselves control threading on internal operations, or should the calling code "above" each module implement threading on the raw functions themselves.

On one side, I can see from a complexity point of view that having to control threading of multiple modules from a central point can be a bit of a mess. However, if the module implements threading on it's own you lose the context and control of individual processes. A compromise could be exposing the thread objects via the interface header file, but then I feel you might be back to the first step again.

Thanks for the perspective, if there's any good examples of open-source stuff that does this I'd love to see it too!

Edit for more info: The modules are currently being designed as an abstract functional block of code, with little exposed outside of configuration variables (so it would be a generic "Camera" interface with different modules implementing the hardware of that specific build or revision). IO operations aren't intensive, but they tend to take a while to complete; so a possibility could be using an exposed bool/enum variable to indicate status?

So I'm working on a growing C program in a Linux / POSIX environment, and I've run into an area where I'm not quite sure how to proceed.

Basically, I'm using a module pattern to develop my code for use with different external hardware and I/O operations (for example: a file module, a camera module, a Serial module, etc.) Some of these operations take a bit of time to complete, and should be placed in their own thread for obvious reasons.

My question basically boils down to this: Should the modules themselves control threading on internal operations, or should the calling code "above" each module implement threading on the raw functions themselves.

On one side, I can see from a complexity point of view that having to control threading of multiple modules from a central point can be a bit of a mess. However, if the module implements threading on it's own you lose the context and control of individual processes. A compromise could be exposing the thread objects via the interface header file, but then I feel you might be back to the first step again.

The modules are currently being designed as an abstract functional block of code, with little exposed outside of configuration variables (so it would be a generic "Camera" interface with different modules implementing the hardware of that specific build or revision). IO operations aren't intensive, but they tend to take a while to complete; so a possibility could be using an exposed bool/enum variable to indicate status?

So I'm working on a growing C program in a Linux / POSIX environment, and I've run into an area where I'm not quite sure how to proceed.

Basically, I'm using a module pattern to develop my code for use with different external hardware and I/O operations (for example: a file module, a camera module, a Serial module, etc.) Some of these operations take a bit of time to complete, and should be placed in their own thread for obvious reasons.

My question basically boils down to this: Should the modules themselves control threading on internal operations, or should the calling code "above" each module implement threading on the raw functions themselves.

On one side, I can see from a complexity point of view that having to control threading of multiple modules from a central point can be a bit of a mess. However, if the module implements threading on it's own you lose the context and control of individual processes. A compromise could be exposing the thread objects via the interface header file, but then I feel you might be back to the first step again.

Thanks for the perspective, if there's any good examples of open-source stuff that does this I'd love to see it too!

So I'm working on a growing C program in a Linux / POSIX environment, and I've run into an area where I'm not quite sure how to proceed.

Basically, I'm using a module pattern to develop my code for use with different external hardware and I/O operations (for example: a file module, a camera module, a Serial module, etc.) Some of these operations take a bit of time to complete, and should be placed in their own thread for obvious reasons.

My question basically boils down to this: Should the modules themselves control threading on internal operations, or should the calling code "above" each module implement threading on the raw functions themselves.

On one side, I can see from a complexity point of view that having to control threading of multiple modules from a central point can be a bit of a mess. However, if the module implements threading on it's own you lose the context and control of individual processes. A compromise could be exposing the thread objects via the interface header file, but then I feel you might be back to the first step again.

Thanks for the perspective, if there's any good examples of open-source stuff that does this I'd love to see it too!

Edit for more info: The modules are currently being designed as an abstract functional block of code, with little exposed outside of configuration variables (so it would be a generic "Camera" interface with different modules implementing the hardware of that specific build or revision). IO operations aren't intensive, but they tend to take a while to complete; so a possibility could be using an exposed bool/enum variable to indicate status?