Für SL:
Scripts haben nach dem Kompilieren auf dem Server immer wieder "Stopmarken" zwischen wesentlichen Teilen und Events, an diesen Stellen kann das Script angehalten werden. Das ist etwa nach einem Abarbeiten von Events, aber auch nach bestimmten Funktionen. Und z.B. wenn für einen TP nötig kann das Script im Speicher an dieser Stelle eben auch komprimiert, an einen anderen Server geschickt, dort ausgepackt, in den Speicher des neuen Servers geschrieben und dort ab der selben Stelle weiter ausgeführt werden, an der es angehalten wurde. Scripts laufen also nicht kontinuierlich durch, sondern immer nur von Stopmarke bis Stopmarke.
Am Ende jedes Frames, der optimalerweise höchstens 22ms lang ist (da der Server mit 45 FPS läuft), schaut die Script Engine jetzt einfach nach welche Scripts im Simulator vorhanden sind und welche Scripts mit dem Weiterlaufen der Stopmarken dran sind. Ist im Frame freie Zeit für die Scripts vorhanden, dann werden sie weiter ausgeführt, die Stopmarken werden nach und nach abgearbeitet. Dabei nimmt der Server auch in Kauf, dass die FPS nicht stabil bleiben und leicht sinken, auf z.B. 30 FPS (den genauen Wert kenn ich nicht, das dürfte aber um den Dreh sein), das entspricht dann einer Frametime von 33ms. Reicht diese Zeit allerdings nicht mehr aus um alle Scripts mit einer Stopmarke abzuarbeiten, dann kommen die Stopmarken, die weiterlaufen hätten sollen, dies aber nicht mehr geschafft haben, an den Anfang des Stoppmarken-Stapels des nächsten Frames, die Betroffenen Scripten laufen nicht weiter und verbrauchen auch keine CPU-Zeit und stören den Server in diesem Frame nicht weiter. Erst wenn Zeit über ist und das script dann an der Reihe ist wird es wieder fortgesetzt. Und belastet den Server wieder mit Rechenzeit. Hat ein Script nun laufende Delay-Time, dann meldet es eben für eine gewisse Zeit einfach keine Stopmarken mit "ich will weiter laufen" - es wird im jeweils aktuellen Frame einfach nicht abgearbeitet. Belegt also eben auch keine CPU-Zeit außer für die Meta-Verwaltung des Delays in der Script-VM. Es ist eben dadurch keine Server-Last.
Deswegen kann man zumindest in SL bedenkenlos llSleep auch für lange Zeiträume nutzen wenn Will, dass ein Script überhaupt nichts macht in der Zeit. Ein Script mit z.B. schon 600s = 10 min Script Time verbraucht bereits nach kurzer Zeit "0.000050 ms of CPU time" oder so während es "läuft". Also eigentlich nichts. CPU-Last wird erst dann wieder generiert, wenn die Schlafzeit vorbei ist.
Zu viele Events können sich auch nicht wirklich aufstauen, pro Script können nur 64 Events in einen Queue. Werden mehr Events getriggert, dann werden die so lange ignoriert bis wieder Platz ist.
EDIT: Und jeder Event wird während des Sleep-Zustandes nur ein mal getriggert. D.h. wenn während des Sleep vier mal das Prim berührt wird, dann wird trortzdem nur ein einziges mal der touch-Event ausgelöst und nicht vier mal.
Das Einzige Problem mit llSleep, aber auch mit llSetTimerEvent ist, dass SL nicht "rund läuft", d.h. es kann eine time dilation geben. Dabei entsprechen 45 FPS eben einer time dilation von 1.0 und 22 FPS dann einer time dilation von 0.5. Was für Scripte leider bedeutet, dass die Scriptzeit in weiten Teilen nur halb so schnell vergeht wie normal. Das kann in ganz extremer Form dann auftreten, wenn eine Region leer ist und der Server auf "region idling" umschaltet, d.h. die Region wird zum Energiesparen auf "ganz langsam" runter gefahren und allenfalls ganz kurz für wichtige LSL-Funktionen (Netzwerkkommunikation) wieder auf 45FPS gesetzt.
==> Deswegen ist es in SL leider unerlässlich mit einem extrernen Zeitgeber (llGetUnixTime, llGetTimeStamp etc.) zu arbeiten, wenn man einen sehr langen Timer Event oder wenn irgendwie möglich einen sehr langen Sleep Event verwendet (der braucht weniger Ressourcen als ein Timer) und korrekte Zeitintervalle braucht. D.h. man muss z.B. das Script
kurz vor dem geplanten Zeitintervall wieder aufwachen lassen um sich dann den richtigen Zeitpunkt mit einem schnelleren Timer für die entsprechende Aktion zu holen (z.B. jede Sekunde oder alle 5s mal abgleichen).
Für OpenSimulator:
Die Script-Engine ist dort komplett andes aufgebaut. Leider ist diese Software eher bisschen bescheidener und einfacher programmiert, deswegen ist llSleep da ein kleines Problem.
Das Problem ist, dass jedes Script dort mit einem Even einen eigenen Thread in der CPU belegt. Das ist normal kein Problem, denn Events sind für gewöhnlich Dinge in einem Script, die ziemlich schnell abgearbeitet sind. Worauf der Thread wieder freigegeben wird. Und normalerweise sitzt das Script einfach im Speicher rum und macht nichts ausser auf neue Events zu warten um damit einen Event zu belegen.
Läuft in einem Event allerdings ein llSleep - oder aber auch eine andere Funktion mit einem großen Delay wie llEmail ! - dann wird der Event eben nicht abgearbeitet und der Thread wird nicht freigegeben. Bei llEmail bedeutet das z.B., dass bei jedem Aufruf der Thread für 20s belegt wird. Aber auch andere Funktionen wie llSetLinkPrimitiveParams haben so ein Delay, hier sind es 0.2s. Was aber mit einer hinreichenden Anzahl an Scripts, die diese Funktion hinreichend schnell aufrufen direkt dazu führen kann, dass der Server so stark belastet wird, dass die Script-Engine einfach dicht ist.
Genau deswegen sollte man in OpenSimulator wenn irgendwie möglich mit Funktionen, die ein eingebautes Delay haben, äußerst sparsam umgehen und diese wirklich nur dann verwenden, wenn es gar nicht anders geht. Und llSLeep wenn irgendwie möglich nur für kurze Zeiten nutzen damit die Events wieder schnell abgearbeitet werden können.
Siehe auch
http://www.kitely.com/forums/viewtopic.php?f=26&t=1149
Argus fragte allerdings nach riesigen Zeitintervallen, deutlich länger als eine Minute (die mit Sicherheit unkritisch ist). Und wenn es um große Zeiten geht, ist llSleep immer deutlich ressourcensparender als eine Schleife, die dauernd das Script beschäftigt und irgendwelche Zeiten überprüft.