05 SampleProgram

Sample Program

SampleProgram is a windows console application project that builds and integrates the features of this solution.

Features

SampleProgram consists of main, ripper, and progress_tracker. main is the main program and entrypoint that uses ripper to create an ISO 9660 image of any CDROM/DVD media found in the drive.

ripper demonstrates the RAII paradigm by locking the cdrom tray door, and unlocking it on all return paths (but in this case there is a design limitation that is discussed below). It also uses the same RAII technique to claim and release exclusive access to the underlying physical cdrom device (this makes the cd filesystem temporarily unavailable during the rip operation). Again the objective is to ensure that the unwinding of an operation is comfortably and reliably performed on all return paths.

progress_tracker is an example of task based threading - an object (with state) is created, and its functor () is used as the target of a std::async call in main(). std::async returns a std::future which can be used to block the launching main thread, and to await and interrogate the eventual task outcome. Notice that such a task is easy to set-up, launch and synchronize. It can also log without restrictions, and throw exceptions, which may (optionally) be off-loaded for exception handling in the invoking thread. This may seem to be just what you would expect, and to value and appreciate this richness, simplicity and ease of use, you probably need to have experienced some of the history of cooperative, pre-emptive, multi-tasking in the preceding years.

The object instance created in main for this purpose is called 'tracker' and its state includes a reference to a std::atomic 'progress'. The same reference has been added to parameter frames of the constructors (Ripper, CdromDevice) which track (maintain the progress value) in the main thread. This approach provides (thread safe) passing of the progress indication to the progress tracker thread, which is responsible for informing the operator.

Limitations

1. The main program makes fixed hard coded selection of the first physical cdrom drive found in the system at runtime. It logs to a fixed hard coded log file called "ripper.log", and creates an iso image file in the fixed hard coded location "cdrom_image.iso".

2. The main program now shows a progress indication during the rip/read operation, because this typically takes some minutes to complete. However, the design of this feature is not rigorous making use of a convenient trick to simulate an out-of-resource limitation and to exploit some pre-existing exception handling code. That approach has a known drawback, in that it will not provide a reliable progress indication if an actual out-of-resource exception occurs and needs to be handled. That drawback could be eliminated, but because I've never seen this scenario in real life, I can live with it for the sake of sample code that is easier to follow. Just be aware, in case you spot a dirty hack that is fundamentally unsound, and wonder why. There is full disclosure in code comments.

3. Large dvd images can exceed the virtual address space available to the 32-bit build binaries. In these circumstances an exception will be reported (to the console).

4. Image files ripped from cd's that are not ISO 9660 format, obviously won't be ISO 9660 compliant, and the fixed .iso extension of the image file will then be a falsehood. Windows will advise you that such a file is 'corrupt'. On Windows 10 Home 1803 edition the file won't be mountable, and if you try, you will need to eject the failed new volume (visible in the left panel of the file explorer), before the backing file can be accessed or deleted. With all of Windows 7-10 you'll see something similar to this.

5. Signalled program termination (Eg ctrl+break ctrl+c) demonstrate an important limitation of RAII. Destructors are not invoked if a process is signalled to stop. A terminated process releases its resources more brutally (without unwinding the stack or calling any destructors). This means that system state can never be reliably restored using RAII techniques alone. A signal handler has been provided in main.cpp, which issues a preventative speculative (physical) unlock of the cd rom tray door mechanism whenever the program is signalled to stop. Notice that the signal handler does nothing to release the exclusive access lock, as the system will do this automatically when the corresponsing device handle is closed (as happens when a process terminates). Notice also that despite the limitation and need to mitigate it, RAII (scoped locks) are still an excellent way to apply locks.

6. There is no housekeeping done with log files which could expand indefinitely to consume all disk space.