freenode/#clasp - IRC Chatlog
Search
15:27:35
Shinmera
I can only see it mattering if you copy the data to a new place and remove the old one due to size increase, and the old data gets changed in the meantime too
15:27:40
beach
Shinmera: Are you assuming that the memory cells that define the contents do not change?
15:28:37
Shinmera
either way, all you need to "lock" is making sure that the old array content does not get freed until you're done with your access.
15:29:25
beach
Shinmera: I am thinking, if you have a very large array, then you adjust it to be a very small one, you would want to reallocate a smaller contents vector.
15:29:39
Bike
https://pastebin.com/b28079YY if i do this, every few runs i get an assertion failure because the array element = 0, which i think is wrong
15:31:24
Shinmera
I would bet on all implementations putting the burden of thread safety on the user
15:33:29
Shinmera
I guess if you could hold on to not just a pointer to a memory region, but also to that region's length, then the problem would fall away, since the GC would not be allowed to realloc until you're done with your aref.
15:34:59
beach
Shinmera: My plan for SICL is to make the contents vector (i.e. the "rack") internally consistent, and for adjust-array to be obliged to allocate a new contents vector.
15:36:44
beach
I want it to be possible to declare that it is completely safe, i.e. that it is impossible to crash the system (barring defects of course).
17:41:47
kpoeck
I - perhaps always - fail with a variant of The function PRIMOP::INLINED-TWO-ARG-> is undefined.
17:45:40
kpoeck
I thought I just fix disassemble so that it does not fail when llvm-sys:get-name is called on a CORE:CLOSURE-WITH-SLOTS
17:49:51
drmeister
kpoeck: There seems to be a complicated (I haven't dug into it) interaction between parallel building, inlining and incremental builds that don't work together.
17:51:03
drmeister
I'm getting ready to rearrange the cclasp build/link system and so I haven't dug into it to fix it - because it is probably not fixable and it's a symptom of the way that startup works right now.
17:52:17
drmeister
So try building cclasp with -j1 - I think that will build incrementally like it always did.
17:52:52
drmeister
Or give up on incremental builds, wipe the cclasp object files and build in parallel
18:17:37
drmeister
With MPS allocations are done by bumping a pointer - I'm trying to get the allocators inlined into code.
19:49:09
kpoeck
COMMON-LISP-USER> (disassemble #'car) Disassembling function: #<CLOSURE-WITH-SLOTS@0x10b776308 CAR :type cclasp lambda-list: (X) :fptr 0x103654660> 0x103654660 <# 0+0> pushq %rbp 0x103654661 <# 1+1> movq %rsp, %rbp 0x103654664 <# 2+4> pushq %r15 0x103654666 <# 3+6> pushq %r14 0x103654668 <# 4+8> pushq %rbx 0x103654669 <# 5+9> subq $0x148, %rsp 0x103654670 <# 6+16> movq %rdx, %r15 0x103654673 <# 7+19> movq %rsi, %rbx 0x103654
19:54:01
kpoeck
If we ever manage to have ci, perhaps the regression tests can be included after every build