Deployment

The user-mode library comes in two forms:

  • As .dcu files, for linking to the application statically.
  • As .bpl files (compiled package files), used when the application is built with packages, named dclcbfssync26.bpl.

When using packages, deploy the .bpl file to the target system and place it next to the application's .exe file.

The VCL components require

  • Windows: dynamic libraries (DLLs), named cbfssync26.dll (available separately for x64 and x86 processor architectures)
  • Linux:a dynamic library, named libcbfssync.so.26.0, for x64 processor architecture
  • macOS: a dynamic library, named libcbfssync26.0.dylib, for ARM64 and x64 processor architectures

The libraries can be found in the "lib" and "lib64" (Windows only) directories.

When deploying the application, copy the native library with the proper architecture to the target system and place it next to the application's executable file (on Windows, it has the .exe extension).

Alternatively, the native library may be placed into one of directories, the paths to which are contained in the

  • Windows: PATH environment variable, such as C:\Windows\System32 (or C:\Windows\SysWOW64 when deploying a 32-bit application on a 64-bit Windows system)
  • Linux: LD_LIBRARY_PATH environment variable
  • macOS: DYLD_LIBRARY_PATH environment variable

Threading and Concurrency

The component utilizes different underlying technologies on different operating systems. Because of that, the threading model exposed to applications depends in part on the platform component runs on.

NOTE: Even when configured for minimal concurrency, the component always fires events in the context of some worker thread, and not in the thread the component was originally created on. Therefore, applications must be sure to synchronize operations between event handlers and other threads as necessary (including, but not limited to, calls to the component instance, unless a method is explicitly documented as callable within events).

Configuring Event Concurrency

The SerializeEvents property controls whether events relating to different files should be allowed to fire in parallel on several worker threads, or serialized on a single worker thread. By default, this property is set to seOnMultipleThreads, and events for different files are allowed to fire in parallel.

Windows: Generally speaking, the component always enforces per-file event serialization; that is, events relating to the same file are always fired in sequence regardless of the property value. With per-file event serialization already ensured, the most important concurrency-related consideration is whether to enforce multifile event serialization as well, which is what SerializeEvents controls. When SerializeEvents is set to seOnMultipleThreads, the MinWorkerThreadCount, MaxWorkerThreadCount, and WorkerInitialStackSize configuration settings let the application tune the worker thread pool. These settings are ignored when SerializeEvents is set to seOnOneWorkerThread.

Linux: When SerializeEvents is set to seOnMultipleThreads, the component may fire events related to the same file concurrently in several threads. If the application is not prepared for that, it should use seOnOneWorkerThread mode.

macOS: The events always fire on a single worker thread, and the SerializeEvents property has no effect.