Advanced features of Full API

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.

• WebAssembly Threads has better performance, since it supports multithreading but currently is only supported on Google Chrome for Desktop. This may change in the future.
• Emscripten (which compiles both non-threaded WebAssembly and asm.js implementations) starts up a little faster and is compatible with most browsers, but has slower runtime performance.

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().

1async function main() {
2  try {
3    const doc = await PDFNet.PDFDoc.create();
4    doc.initSecurityHandler();
5    // documents require locking
6    doc.lock();
7    // do stuff with document
8  } catch (err){
9    console.log(err);
10  } finally {
11    // unlocks the document
12    await doc.unlock();
13  }
14}
15PDFNet.runWithoutCleanup(main);
16// if you use PDFNet.runWithCleanup(main), no need to unlock

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()

1async function main() {
2  // ...
3}
4// Automatically locks all worker operations
5PDFNet.runWithCleanup(main);

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.

1const doc = await PDFNet.PDFDoc.create();
2doc.initSecurityHandler();
3doc.lock();
4// ...
5
6// This section is only required to ensure the page is available
7// for incremental download. At the moment the call to requirePage must be
8// wrapped in this manner to avoid potential deadlocks and
9// allow other parts of the viewer to run while the page is being downloaded.
10doc.unlock();
11await PDFNet.finishOperation();
12// requirePage(pageNum) ensures that the first page is downloaded before it is accessed.
13await doc.requirePage(1);
14await PDFNet.beginOperation();
15doc.lock();

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:

1async function main() {
2  try {
3    // documents require deallocation
4    const doc = await PDFNet.PDFDoc.create();
5    // object that requires deallocation
6    const page_iter = await doc.getPageIterator();
7    // object that requires deallocation
8    const writer = await PDFNet.ElementWriter.create();
9  } catch (err){
10    console.log(err);
11  }
12}
13
14// deallocates all objects once main finishes running
15PDFNet.runWithCleanup(main);

Example of individual deallocation:

1async function main() {
2  try {
3    const doc = await PDFNet.PDFDoc.create();
4    const page_iter = await doc.getPageIterator();
5    const writer = await PDFNet.ElementWriter.create();
6  } catch (err){
7    console.log(err);
8  } finally {
9    await doc.destroy();
10    await page_iter.destroy();
11    await writer.destroy();
12  }
13}
14PDFNet.runWithoutCleanup(main);

Example of stack-based deallocation:

1async function main() {
2  try {
3    await PDFNet.startDeallocateStack();
4    const doc = await PDFNet.PDFDoc.create();
5    const page_iter = await doc.getPageIterator();
6    const writer = await PDFNet.ElementWriter.create();
7    await PDFNet.endDeallocateStack();
8  } catch (err){
9    console.log(err);
10  }
11}
12PDFNet.runWithoutCleanup(main);