It is limited to two OS threads (one for Pike, one for libraries, or maybe one for each library), or does it have the possibility of one OS thread per library call (theoratically resulting in X OS threads, which might or might not be faster here if the system has more than two cores)?
To put it another way:
Pike always have one OS - pthread_create, _beginthread, etc - thread per thread, it just that it can't run more than one of the threads at a time in the interpreter.
The rest will be waiting for the interpreter lock, unless they are doing something that doesn't need it, like image- or file operations. In those cases they release the interpreter lock, so other threads can grab it. It will more or less look like this:
real thread started: lock(the interpreter lock) forever do pike calculations and variable operations
while doing this, sometimes (function call, loopbacks, etc) unlock(the interpreter lock) // let other interpreter threads run lock(the interpreter lock)
in some functions, like Image.JPEG.encode or file read: unlock(the interpreter lock) do the heavy stuff // let other interpreter threads run lock(the interpreter lock)
So it's not limited, but every Pike thread will use up real thread resources like stack address space. (This is a problem if you plan on having an application with 1000 threads.)