Offline
But, I can't help but notice that I'm getting a lot of permission denied errors for the files; meaning that the file handles aren't being closed when they are supposedly being closed from Lua.
Can you explain this, or fix it, DC?
Forum
CS2D General [BUG] Lua file handles not releasing?
[BUG] Lua file handles not releasing?
8 replies
1 
But, I can't help but notice that I'm getting a lot of permission denied errors for the files; meaning that the file handles aren't being closed when they are supposedly being closed from Lua.
Can you explain this, or fix it, DC?
Steps to undertake:
1. Make sure that you've closed all file descriptors before accessing them again
2. Make sure that you aren't serializing descriptors into reference objects (tables and whatnot) because a weak reference to the descriptor will be kept alive even if you do call close to the original descriptor (Lua may propagate the changes if file's userdata handles __gc correct, but better learn from Java's mistakes and avoid this kind of pattern)
3. Make sure that you can actually open the file when the script is running. Since the read and write calls are meant to be instantaneous, in order to avoid collision, you shouldn't have any problems accessing files if you use the open-read-close and open-write-close paradigm.
If all of the above fails, then you know that this is not Lua nor a script's fault.
edited 1×, last 24.10.10 09:30:38 pm
The handle is released after a minute or so, but this still isn't acceptable.
Quote
1. Make sure that you've closed all file descriptors before accessing them again
2. Make sure that you aren't serializing descriptors into reference objects (tables and whatnot) because a weak reference to the descriptor will be kept alive even if you do call close to the original descriptor (Lua may propagate the changes if file's userdata handles __gc correct, but better learn from Java's mistakes and avoid this kind of pattern)
3. Make sure that you can actually open the file when the script is running. Since the read and write calls are meant to be instantaneous, in order to avoid collision, you shouldn't have any problems accessing files if you use the open-read-close and open-write-close paradigm.
2. Make sure that you aren't serializing descriptors into reference objects (tables and whatnot) because a weak reference to the descriptor will be kept alive even if you do call close to the original descriptor (Lua may propagate the changes if file's userdata handles __gc correct, but better learn from Java's mistakes and avoid this kind of pattern)
3. Make sure that you can actually open the file when the script is running. Since the read and write calls are meant to be instantaneous, in order to avoid collision, you shouldn't have any problems accessing files if you use the open-read-close and open-write-close paradigm.
1
2
3
2
3
f = assert(io.open(tostring(USGN)..'.txt','w')) f:write(blar) f:close()
That's the format I've been using.
I don't know how the io module of Lua works. I didn't even use it yet but this problem must either be caused by Lua itself or by the implementation of Lua in blitzmax (which both have not been created by myself als already said).
Also, make sure that f is not a global variable (append local in front of it)
Here's a quick fix if it's still not working, this basically emulates a thread dispatch for queued items that were previously blocked, however it's only for cases where the write or read operation is long enough so that the file is still blocked when the minute hook calls it (AKA: it blocks and routes asynchronous access through a queue):
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
queue_map = {}
for path, data in pairs(queue_map) do
local f = io.open(path, 'w')
if f then
queue_map[path] = nil
f:write(data)
f:close()
end
end
local f = io.open(path, 'w')
if not f then queue_map[path] = blargh else f:write(blargh);f:close() end
As a sidenote: I've previously written an async storage system that frequently requests for access to a file, I've never encountered any problems with it so I don't think Lua or CS2D's implementation of Lua is at fault here.
Writing is done once a minute.
Actually, come to think about it, I've been forgetting to localize everything...
Hm.
1