If your app has more than one thread (due to either a sproc(2) or a pthread_create(3P)), and you could potentially manipulate VL objects from more than one thread at a time, make sure you follow these rules.
When you make VL calls, you pass in VL objects such as VLServer, VLPath, VLNode, VLBuffer, etc. All of the objects hang off of the VLServer. You cannot create any of the other objects without first creating a VLServer. All of the arguments to a VL call must derive from the same VLServer.
In a given process share group, there may only be one VL call executing at a time whose arguments derive from a given VLServer. This even includes VL calls which do not explicitly take a VLServer as an argument (for example, vlBufferAdvise).
You may use objects derived from a given VLServer in any number of threads, as long as you make the use in each thread mutually exclusive of a use in any of the other threads via some locking scheme (such as usnewsema(3P) or pthread_mutex_init(3P)).
This has been true since the earliest days (vino and ev1). Violating this rule will result in intermittent core dumps on all video platforms. Because O2 video does not use a daemon (videod) like the other video systems, you may find that violating this rule produces core dumps more often on O2, because in the deamon-based video scheme, the unix-domain-socket to videod sometimes serialized operations for the user (note sometimes).
If you want to make uncoordinated VL calls from more than one thread, you will need more than one VLServer.