Generators and Yield-- persuasive tools from Python &c.

[JohnD|Dyalog]

So, this:

      {⎕tget ⍵}&¨⍳60

doesn't create OS threads nor consumes visible CPU time.
This:

      {⎕tget ⍵}&¨⍳61

doesn't create OS threads but it saturates a CPU core.
I repeat: if I had noticed this behaviour before, I cannot remember now. But it looks like a somewhat serious limitation to the usage of []T's.
Is it related to the fact that WaitForMultipleObjects can only wait for a maximum of 64 object handles? (Constant MAXIMUM_WAIT_OBJECTS is 64).

By the way: I tried all my experiments using the 32 bits, classic version of the Windows interpreter. Right now I have no means (nor much interest to be honest :-)) to test on different OSes.

Yes, it's that. The interpreter attempts to use semaphores where it can to reduce CPU usage with multiple threads. There are techniques to wait on more that 64 handles, but currently the interpreter doesn't use them. I suspect that in some case the process of generating the list of semaphores may consume more CPU than just letting the thread switch process occur,and this may become more true if we support a larger number of semaphores. Of course, it's hard to confirm that.

[paulmansour]

Stefano... thanks for all the info. Trying to digest it all.

[paulmansour]

This is interesting stuff. I had never heard the term generator before, but have read a little bit about it now. Thanks for introducing me to the concept!

I think I have unknowingly implemented something like a generator in Rumba (My APL Web Sever). Once I get a connection, I create a "connection" thread, which uses ⎕TGET to wait for data that is handled by the main thread, which uses ⎕TPUT to chuck data to all the connection threads. So I think the main thread, which is just waiting for data on the socket, is a generator, and the connection threads are then all waiting for the next value from it.

Anyway, when I have a chance I will go over my code in light of the formal definition of a generator.