External-library routines

It is recommended that a C UDR avoid the use of routines from existing external libraries. Some of these external routines might contain system calls that are restricted in your VP. If your C UDR must use an external routine, it might be ill behaved.

Avoid calling the following kinds of external library routines, which are not safe in the CPU VP:

Routines that do blocking I/O, such as routines that open files
Routines that dynamically allocate memory, such as malloc()
Routines that allocate static memory

To execute one of these routines safely in a UDR, the following steps are possible:

Divide the UDR into critical-code sections and DataBlade-API-code sections.
Execute the UDR in a user-defined VP.

The following text explains these steps.

Important: Any external-library routine that uses signals cannot be used in a C UDR. Do not use this suggested workaround for any external library call that uses signals.

For an external routine to execute safely, the thread that executes the UDR must not migrate out of the VP as long as the UDR uses the unsafe resources (open files, memory allocated with malloc(), or static-memory data). However, DataBlade API functions might automatically yield the VP when they execute. This yielding causes the thread to migrate to another VP.

Therefore, you cannot interleave DataBlade API calls and external routines in your UDR. Instead, you must segment your C UDR into the following distinct sections:

Critical-code sections
These sections contain only the external-library calls that are not safe in the CPU VP. Before execution leaves the critical-code section, any unsafe resources must be released: open files must be closed and memory allocated with malloc() must be deallocated.
DataBlade-API code sections
These sections contain only DataBlade API functions. No external-library functions that are not safe in the CPU VP exist in these sections because any DataBlade API function might cause the thread to migrate.