A Win32 Perspective:

• Kernel.
• Preemptive.
• (On win32) yield() translates to sleep 0; which is the standard way for a thread (or process) to give up the rest of its current timeslice.

  However, if there are no other threads eligable to run, it can lead to the same thread being immediately given another timeslice, which if it has nothing to do, it will again immediately yield. And if there are still no other threads eligable to run, it is again immediately given another timeslice... As you can see, this can lead to intense context swapping, maxed out cpu, energy usage etc.

  For most cases, it is better to use a sleep (or Win32::Sleep) with a short duration, as this can reduce cpu usage and context thrashing to almost 0 with little or no affect upon the responsiveness or throughput of the application.

• What are the 'break points' or commands that may be preempted?

  That is a really vague question to ask on a perl forum. As we are talking kernel threads, the scheduler can interupt between any two machine level instructions unless the programmer takes steps to prevent it by using some serialisation mechanism like Critical Sections (not available from Perl).

  At the Perl-level, it is really hard to discuss as Perl itself does some serialisation for its own internal integrity. And the C-runtime libraries do some serialisation for their own internal integrity.

  For user-level Perl code, you theortically only need concern yourself with controlling access to variables explicitly marked as shared. However, the user does have to concern themselves with access to process-global entities like files, directories, sockets etc.

• what functions or operators are atomic?

  As above, are you talking Perl-level functions and operators; C-level functions and operators; machine-level?

• how are signals handled? I have found differing write ups that don't versions.

  Very platform specific. Whilst Perl attempts to emulate a very limited set of signal-type behaviours on Win32, and later versions of threads have attempted to extend that emulation to inter-threading, neither is very satisfactory.

  (ITMO) attempting to use signals for inter-thread communications is a bastardisation of a primitive mechanism that doesn't work anywhere well.

This should be simple if I can find the correct "FM" to "RT"; or a link to such.

If you find one, please come back and post a link. I'd like to read it also.