Spawning a new Throwaway Thread

General APL language issues

Spawning a new Throwaway Thread

Postby paulmansour on Mon May 16, 2016 2:25 pm

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.
paulmansour
 
Posts: 343
Joined: Fri Oct 03, 2008 4:14 pm

Re: Spawning a new Throwaway Thread

Postby DanB|Dyalog on Mon May 16, 2016 2:40 pm

How about
+{}&0
?
DanB|Dyalog
 

Re: Spawning a new Throwaway Thread

Postby paulmansour on Mon May 16, 2016 2:44 pm

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?
Last edited by paulmansour on Mon May 16, 2016 2:56 pm, edited 1 time in total.
paulmansour
 
Posts: 343
Joined: Fri Oct 03, 2008 4:14 pm

Re: Spawning a new Throwaway Thread

Postby paulmansour on Mon May 16, 2016 2:45 pm

Dan, yes! I am an idiot!
paulmansour
 
Posts: 343
Joined: Fri Oct 03, 2008 4:14 pm

Re: Spawning a new Throwaway Thread

Postby gil on Thu Aug 11, 2016 8:16 am

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 ;)
gil
 
Posts: 68
Joined: Mon Feb 15, 2010 12:42 am


Return to Language

Who is online

Users browsing this forum: No registered users and 1 guest