Re: [igraph] Multi-threading and igraph

[Tamas Nepusz]

> Actually, as a solution, I was thinking about assigning a context to
> each thread, and this would store the thread-local data. Then at the
> beginning of a thread you would need to call an extra function to
> allocate this context, but maybe this is not a big deal.
Yes, but this does not save us from having thread-local variables as the 
pointer to the current thread context must be stored in a thread-local 
variable. Or, alternatively, the caller may store it when it calls the function 
that allocates the context, but then this pointer must be passed on to *every* 
igraph function that calls IGRAPH_CHECK and IGRAPH_FINALLY. This would change 
the API of almost every function. By the way, this is the solution chosen by 
the Java Native Interface (JNI) -- practically one has a JNIEnv* pointer which 
points to the thread-local context, and JNIEnv* pointers are passed around by 
pretty much every JNI function.

By the way, wouldn't it be useful now to start a separate mailing list (say, 
igraph-devel) for development-related questions and leave igraph-help for 
support questions only?

> I don't like the gcc-specific aspect of the thread-local thing, but maybe 
> there is a portable solution as well.
The Microsoft Visual C++ compiler also has its own solution, e.g.:

__declspec(thread) int variable;

So we could simply go with:

#ifdef __MSVC__
#  define IGRAPH_THREAD_LOCAL __declspec(thread)
#elif __GNUC__
#  define IGRAPH_THREAD_LOCAL __thread
#else
#  define IGRAPH_THREAD_LOCAL
#endif

-- 
T.