Spawning a new Throwaway Thread

[paulmansour]

Does anyone have any particular idiom they use to spawn a new thread, that does nothing and immediately, completes, just for the thread id?

We can do:

      +&0

But then we get the result of the function spilling into the session. Or we can do

      {z←0}&0

Any thing better? It all appears very fast, just wondered if there is commonly used expression for this. (To the extent thread use is common!)

The backstory on this is that I am using a fair of amount of TGET and TPUT. I always use thread ids as the tokens, usually the thread I am in, or some other live thread. However, there are times when I need a token that is unrelated to any live thread. The only way (I can think of)is to get this and avoid conflicts is to spawn a thread and get a new id.

[DanB|Dyalog]

How about
+{}&0
?

[paulmansour]

Also, there has been some discussion recently about using tokens and how it is difficult to integrate different apps or utilities because the token pool is global to the workspace. If everyone agreed to use only thread ids as tokens, and only thread ids that your app creates, would not that be a solution to the problem?

[paulmansour]

Dan, yes! I am an idiot!

[gil]

A bit late, but I have just hit the issue now that I try to use both Rumba and the synchronisation tools authored by Stefano.

My understanding is that using a thread number is only safe as long as the thread outlives the use of the token. It may be a very unlikely event, but is a flaw.

I can think of two options:

1. A new pair of system functions

      ⎕TNEW/⎕TDROP

generates and releases tokens. The interpreter would then keep track of tokens issued and in use, exactly like it does for thread IDs, with the difference that releasing tokens must be done explicitly by the application.

2. A standard synchronisation toolset is developed in APL and used by all open-source libraries that use tokens. This would manage the allocation and release of tokens.

Option one would probably work faster, but both would require developers to agree to use the new approach when dealing with tokens. In theory option one could allow the interpreter to reject a ⎕TPUT of a token that had not been issued yet, but that is probably not going to go down well with current systems ;)