Project directory structure

[Jef Driesen]

On 2013-04-03 20:52, Thiago Macieira wrote:
> However, Dirk mentioned threading, so I'd actually recommend a little
> refactoring here: use QThread, which abstracts away the Win32 
> threads. The
> download function is a simple, blocking function. The completion of 
> the
> download is simply the fact that the function returned. (I haven't
> investigated whether such a function exists in libdivecomputer and 
> whether
> there are mutexes involved, which would complicate the situation a 
> little)

All libdivecomputer functions are blocking. There are no threads or 
mutexes internally. All libdivecomputer objects are supposed to be 
accessed from a single thread only. If access from multiple threads is 
desired, the application should take care of proper synchronization. I 
have no intentions to change this model.

There is however one exception that I'm considering. A libdivecomputer 
context object (dc_context_t) is automatically inherited from the device 
object to the parser object. This causes trouble when attempting to 
download and parse on different threads, because in that case the 
context object is automatically shared between threads, and the 
application can't protect it because it's all internal. (The application 
can of course use a single mutex for all libdivecomputer objects, but 
that defeats the purpose of doing the downloading and parsing in 
different threads.) So here I may reconsider, and use an internal mutex 
here.

Jef