Pitfalls

There are some considerations to be taken when using synchronous variables.

Every time you call DICE_sync, you should update your variables with DICE_sync_update. That is because, if some variable value changed, the variable itself was freed and reallocated, so your pointers are likely to be outdated. The reason for this apparently stupid behavior is that some types have variable sizes (such as strings), so sometimes the pointer would have to be updated. To avoid clumsiness (this type needs to be updated, this one doesn't), it was decided to make this a standard. Future versions may improve this internally, avoiding the reallocation iff explicitly declared. You can solve this problem easily, and avoid any kind of trouble, declaring your own sync function, and letting it take care of updates, like in this example:

extern FooType *f;

 

int my_sync ( void ) { 

int i;

DICE_sync_update("foo", f); 

i = DICE_sync();

if (i) 

return i;

f = DICE_sync_get("foo");

}

So whenever you want to synchronize you call my_sync, which does all the dirty job for you. See the tests/ directory for more information.

You also have to take care in threaded programs, but you always have to take care when you write a threaded program anyway. I believe that you just need to pay attention to two things:

1. call DICE_init before you fork the threads. Since DICE_init will fork when spawning clients, it's wise not to mix forking and threading.
2. when DICE_sync blocks, waiting for a reply from the server to continue, it does so using read(2). This is a quote from the Linux glibc info pages:

This function [read(2)] is a cancelation point in multi-threaded programs. This is a problem if the thread allocates some resources (like memory, file descriptors, semaphores or whatever) at the time `read' is called. If the thread gets canceled these resources stay allocated until the program ends. To avoid this calls to `read' should be protected using cancelation handlers.

So that's another reason to have a my_sync function.

Threaded programs may also have problems with asynchronous functions, so be sure to read section 4 too.