Frameworks
Integrations
Mendix
SharePoint
Default UI
Modular UI
AnnotationManager
Annotation Types
Customize
Version 11
v11.0
Version 10
v10.12
v10.11
v10.10
v10.9
v10.8
v10.7
v10.6
v10.5
v10.4
v10.3
v10.2
v10.1
v10.0
Version 8
v8.12
v8.11
v8.10
v8.9
v8.8
v8.7
v8.6
v8.5
v8.4
v8.3
v8.2
v8.1
v8.0
Version 7
Version 6
v6.3
v6.2
v6.1
v6.0
Version 5
Version 4
Version 3
Version 2
WebViewer Server
WebViewer BIM
To get started with setting up a full API project, refer to the getting starting guide.
The full API contains several methods for more advanced control over its processes via locking and memory management. This guide will provide an explanation of how to use these features and will also shed some light on the backend processes of the full API.
For optimal performance, the full API uses two different backends to run its processes, WebAssembly Threads and Emscripten.
On Google Chrome the WebAssembly Threads backend will be used by default, while other browsers will use the Emscripten backend.
Locking prevents multiple simultaneous accesses to a PDF document in a Full API process so that it cannot be changed by outside operations.
An Apryse SDK lock is based on two principles:
Reentrant mutex (also known as recursive lock)
Recursive mutex may be locked multiple times by the same process/thread without causing a deadlock.
Readers-writer (RW) lock (also known as shared-exclusive lock)
An RW lock allows concurrent access for read-only operations, while write operations require exclusive access.
Full API contains three main types of locking and unlocking statements:
Locks a PDF document to prevent competing threads from accessing the document at the same time. Threads attempting to access the document will wait in suspended state until the thread that owns the lock calls doc.Unlock()
.
[PDFDoc].lock()
[PDFDoc].unlock()
-Documents are automatically unlocked upon process completion if the user code is being using PDFNet.runWithCleanup()
.
PDFNet.runWithCleanup()
Locks the document to prevent competing write threads (using lock()) from accessing the document at the same time. Read-only threads however, will be allowed to access the document.
[PDFDoc].lockRead()
[PDFDoc].unlockRead()
Threads attempting to obtain write access to the document will wait in suspended state until the thread that owns the lock calls doc.unlockRead()
. Documents are automatically unlocked upon process completion if the user code is being run with PDFNet.runWithCleanup()
.
Obtaining a write lock while holding a read lock is not permitted and will throw an exception. If this situation is encountered please either unlock the read lock before the write lock is obtained or acquire a write lock (rather than read lock) in the first place.
beginOperation()
locks all worker operations on PDFNet.
PDFNet.beginOperation()
PDFNet.finishOperation()
Both PDFNet.runWithCleanup()
and PDFNet.runWithoutCleanup()
call beginOperation()
and end with finishOperation()
, so beginOperation()
and finishOperation()
should only be used when PDFNet needs to be unlocked in the middle of a process.
PDFNet.runWithCleanup()
PDFNet.runWithoutCleanup()
Running multiple unrelated full API operations simultaneously may result in race conditions. This can be resolved by synchronizing the full API operations using a queue. The deck.js sample demonstrates this by queuing its renderPage calls to prevent race conditions on its single shared PDFDraw object.
For this reason, calling beginOperation()
a second time before finishOperation()
is called will cause an exception to be thrown.
There are some cases where unlocking in the middle of a full API process may be required. This usually happens if requirePage()
needs to be called on a document.
The ViewerEdit sample on the samples page shows a situation where manual unlocking and re-locking may be used.
The full API automatically cleans up all objects in a process initialized using PDFNet.runWithCleanup()
once the process has finished running. In almost all cases it is recommended to use this function to avoid memory leaks and complicated memory management.
In some situations you may wish to retain an object after the process has finished. A common example of this would be to create a document and retain it after processing. The ViewerPreprocess sample on the samples page has an example of how this can be done.
[Obj].takeOwnership()
For most use cases using PDFNet.runWithCleanup()
and [Obj].takeOwnership()
is sufficient. However, there are additional ways to manage memory:
Deallocates individual objects. Only objects that derive from PDFNet.Destroyable have this method.
[Obj].destroy()
Stack-based deallocation. Calling endDeallocateStack()
will deallocate all objects that were created since the last call to PDFNet.startDeallocateStack()
.
PDFNet.startDeallocateStack()
PDFNet.endDeallocateStack()
In general, stack-based deallocation is recommended because it is easier to manage for larger sections of code.
Example of default/automatic deallocation:
Example of individual deallocation:
Example of stack-based deallocation:
Did you find this helpful?
Trial setup questions?
Ask experts on DiscordNeed other help?
Contact SupportPricing or product questions?
Contact Sales