This is to follow up the conversion on Hellcat's 'Trigger causes cog to stall' post.
I've done some more research and here are the results:
The number of threads that can run for one cog is five. The reason for the confusion before is because message calls (via the call keyword) will not work after the limit has been reached. But threads will still be created for event messages such as activated. An older thread will be killed for the new one to run.
But which thread will be killed? I'm fairly positive that the last created thread will be killed - the Cog's fifth thread.
SendTrigger() which was causing problems with DeathSythe's example, is not doing anything differently from other verbs like it. Other verbs that trigger cog events - and threads to be created for them - work the same way (such as SendMessage() and CreateThing()). The verb will finish only when all local cogs have received the event - and if they have a message handler for this event, they will start, and if not paused, finish the thread for the event before going back to the original cog.
At first, this seemed pretty wasteful to me - making one cog wait for others to respond when it tries to do something. But this is the way it has to work. If you send a message or trigger, you want the other cogs to have a chance to respond before you continue with the rest of your code.
Suppose you create five threads for a cog. In an example I had with a hotkey's activated message, I made the first four threads wait two seconds and the fifth one wait five seconds before printing a message that they'd finished. The first four could not wake from their sleep until the fifth one did. So I think this proves that JK looks only at the last created thread for a cog... If this highest thread is not ready to resume execution, JK goes on to the next cog. Maybe this explains why JK kills the last created thread when it reaches the thread limit and needs to create a new thread.
Threads will not be created for events that do not have message handlers in the code section - even if the messages are listed in the symbols section.
The purpose of Reset() is to kill all threads running in a cog except the current one - which I think has to be the last created. So Reset() kills all threads below its own.
Timers and Pulses use a thread only when their timer has expired and a thread is needed to run the code in their message. They don't need a thread when they're waiting to run. Pulses must be implemented in almost the same way as timers, they use similar verbs, similar cog flags, and they both have a time value stored with the cog. And since timers can be IDed, it would be very limiting if you could only have fewer than five timers and pulses at a time.
Most of the info above has been pretty well tested, but doubtless there will be discoveries that change some of it. I'd appreciate it if some of you could do some testing to verify this.
------------------
Author of the JK DataMaster, Parsec, Scribe, and the EditPlus Cog Files.
[This message has been edited by SaberMaster (edited July 22, 2003).]
I've done some more research and here are the results:
The number of threads that can run for one cog is five. The reason for the confusion before is because message calls (via the call keyword) will not work after the limit has been reached. But threads will still be created for event messages such as activated. An older thread will be killed for the new one to run.
But which thread will be killed? I'm fairly positive that the last created thread will be killed - the Cog's fifth thread.
SendTrigger() which was causing problems with DeathSythe's example, is not doing anything differently from other verbs like it. Other verbs that trigger cog events - and threads to be created for them - work the same way (such as SendMessage() and CreateThing()). The verb will finish only when all local cogs have received the event - and if they have a message handler for this event, they will start, and if not paused, finish the thread for the event before going back to the original cog.
At first, this seemed pretty wasteful to me - making one cog wait for others to respond when it tries to do something. But this is the way it has to work. If you send a message or trigger, you want the other cogs to have a chance to respond before you continue with the rest of your code.
Suppose you create five threads for a cog. In an example I had with a hotkey's activated message, I made the first four threads wait two seconds and the fifth one wait five seconds before printing a message that they'd finished. The first four could not wake from their sleep until the fifth one did. So I think this proves that JK looks only at the last created thread for a cog... If this highest thread is not ready to resume execution, JK goes on to the next cog. Maybe this explains why JK kills the last created thread when it reaches the thread limit and needs to create a new thread.
Threads will not be created for events that do not have message handlers in the code section - even if the messages are listed in the symbols section.
The purpose of Reset() is to kill all threads running in a cog except the current one - which I think has to be the last created. So Reset() kills all threads below its own.
Timers and Pulses use a thread only when their timer has expired and a thread is needed to run the code in their message. They don't need a thread when they're waiting to run. Pulses must be implemented in almost the same way as timers, they use similar verbs, similar cog flags, and they both have a time value stored with the cog. And since timers can be IDed, it would be very limiting if you could only have fewer than five timers and pulses at a time.
Most of the info above has been pretty well tested, but doubtless there will be discoveries that change some of it. I'd appreciate it if some of you could do some testing to verify this.
------------------
Author of the JK DataMaster, Parsec, Scribe, and the EditPlus Cog Files.
[This message has been edited by SaberMaster (edited July 22, 2003).]
![[http://forums.massassi.net/html/frown.gif]](http://forums.massassi.net/html/frown.gif "http://forums.massassi.net/html/frown.gif")
![[http://forums.massassi.net/html/rolleyes.gif]](http://forums.massassi.net/html/rolleyes.gif "http://forums.massassi.net/html/rolleyes.gif")
![[http://forums.massassi.net/html/tongue.gif]](http://forums.massassi.net/html/tongue.gif "http://forums.massassi.net/html/tongue.gif")