> "Steven J. Dovich" <dovich@tiac.net> writes:
> 
> > The commercial application I referred to earlier is a non-threaded
> > Verilog circuit simulator which provides demand loading for user
> > and third-party code using the PLI/VPI API. Such code is increasingly
> > being written using threads (actually creating threads, not just
> > defensive coding).
> 
> Okay, that's in interesting example. Out of curiosity, do you know if
> the PLI/VPI API address threads at all (permitting or forbidding
> them), or is it entirely silent on the subject?

Those APIs predate the proliferation of threads implementations. The
relevant standards encourage an implementation that would create
reentrancy problems if more than one thread is calling through the API.  
My advice in this context is that all user and third party code
must restrict its interaction with the application to the initial
thread of the process.  If that rule is adhered to, then things
will generally work OK.  The simulator and the PLI/VPI API can
pretend there are no threads, and the external code is responsible
for maintaining the integrity of that fiction.

/sjd