blob: a13b18b4982e7ea031020b2777410dbeefb847f0 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
## async
thread.async(function(res))
despite the name, this function provides a new state running under a new thread. coroutines would be more what you are looking for for async
the argument function is executed by the thread until it has been completed. the res paramater is a function that takes any number of arguments and sets them as the value for the thread:await() call, and kills the thread (safely)
the reason for the res function it because lua_call (in the c api) requires a number or return values before you run the function
the res function also provides some child methods for thread managment
though variables are copied, some may not be able to clone perfectly (complex userdata, lightuserdata, etc..) and the __gc call from the main thread may effect the copy on the new thread. this issue wont be permanent, but it may require a workaround for now.
### res:testclose
res:testclose()
closes the thread if it is being requested to close from async:close
### res:autoclose
res:autoclose()
calls res:testclose() every lua line, using a debug hook
---
### async:await
async:await()
pauses the current thread until the selected thread exits, or calls res(), the return value is whatever the thread passed to res
### async:kill
async:kill()
kills the thread, this may close it in an unsafe way, and should be avoided
### async:close
async:close()
waits for the thread to internally call res:testclose or exit
### async:clean
async:clean()
calls the __gc metamethod, will call async:kill() if it is still running
|
