freenode/#sbcl - IRC Chatlog
Search
8:44:43
rtvd_
I had a look at SBCL manual and it says some scary things about the implementation threading. I was wondering if it is still the case or, perhaps the issues are already resolved.
8:45:40
rtvd_
Specifically, "13.10" says "Large amounts of the SBCL library have not been inspected for thread-safety. Some of the obviously unsafe areas have large locks around them, so compilation and fasl loading, for example, cannot be parallelized. Work is ongoing in this area."
8:46:39
rtvd_
Another issue also mentioned in "13.10" is this "each thread has its own region so this involves no stopping. However, when a region fills, a lock must be obtained while another is allocated, and when a collection is required, all processes are stopped. This is achieved by sending them signals, which may make for interesting behaviour if they are interrupted in system calls."
8:48:55
rtvd_
This one is concerning for two reasons: firstly, if I have native code in a system call, I really do not want it to be interrupted or have the whole system waiting just because of the threads did not receive a signal. Another reason is that if I get it right, the performance may suffer greatly in some cases.
11:20:05
rtvd_
If I write a code (which would inevitably be multithreaded) and it would be crashing because of issues in SBCL itself, I am fairly sure I would be unable to fix it.
11:21:03
rtvd_
Well... The documentation implies that the multithreading aspects of SBCL itself are not well polished.
11:21:32
rtvd_
If there is some code which has not been inspected for thread safety that sounds as if it is possible that it is not thread safe.
11:22:14
stassats
nothing is crashing everything is working, you should just stop reading manuals, like other people
11:22:24
rtvd_
Should I read it like this then: "the code is safe to use but the locking may be too coarse and the code may be sometimes somewhat inefficient"?
11:23:31
rtvd_
OK. I would still need to read them at least occasionally in order to get things done.
11:24:24
rtvd_
OK.. I understand that in a multithreaded code I would have to be doing my own locking for application-specific purposes.
11:26:07
rtvd_
My worry was that SBCL internals may have some tricky bits which may glitch from time to time, largely irrespective of what my code is doing. For example if I have a *special* variable then there is some logic regarding how those work in a multithreaded environment and SBCL is taking care of that. If it fails to do its job correctly - that would be sad.
11:29:35
rtvd_
Well... The code I normally write is usually on the bleeding edge in many ways so it tends to matter.
11:30:25
rtvd_
If you have a thread which is in a native code and that code does not return for a minute, would that block a full GC if that happens to start around that time?
11:32:03
rtvd_
OK. How should I interpret this part then "and when a collection is required, all processes are stopped. This is achieved by sending them signals"?
11:32:22
rtvd_
So collection is required, signals are sent, what happens to the thread which is in that native code part?
11:34:52
rtvd_
Let's say the native code is an endless loop summing up elements of a huge array. A signal is sent to its thread when it is in the middle of the job. Are you saying that the control would be transparently passed to some part of SBCL which would do the GC and then the control will be returned back to that code, so that it won't even notice that something has happened?
11:35:46
rtvd_
I am asking it because there are systems where GC would literally hang for the native code to return and let the interception happen.
11:36:22
rtvd_
OK. So it is doing normal, posix threads and normal OS signals on Linux. Most excellent.
11:37:50
stassats
we actually have a mode where foreign calls are not interrupted, but in reality it performs worse than signals
11:40:15
rtvd_
:) I wonder if there is an efficient way of reading / writing large integers as sequences of bytes or words?
11:40:55
rtvd_
Surely there may be many way to do that and I can come up with lots of particularly ugly ones. But what do people who know Common LISP do?
11:41:38
stassats
i only know Common Lisp, but if i were to need it very fast i would use sbcl internals
11:41:40
Xach
I welcome other suggestions, but in their absence I have found arithmetic to be fine enough for me.
11:45:13
rtvd_
Part of the joy of integers is that they already come with all the operations and are quite easy to work with.
11:46:25
rtvd_
But perhaps using arrays is what I should do sometimes. If I just need to do basic arithmetics that should do nicely.