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.
14:19:31
phoe
to quote the original reporter: "it seems it's impossible to unfuck sbcl image after this. I tried remove-method, fmakunbound, changing the struct again (this time using recklessly-continue) but the method still works only once after recompiling
14:21:52
phoe
SBCL allows to proceed with a CONTINUE restart though, that's why I'm posting this on #sbcl
14:25:02
phoe
"uninterning the structure symbol and then recompiling actually worked! and before that I also found that adding another argument to method also fixes it"
14:26:01
_death
didn't work for me.. even with a gf with a different name only defined for the new struct definition
14:30:25
_death
interesting because recently I wrote some defstruct heavy code (and got to know new pitfalls.. e.g., slots without initializers (that sbcl &aux commit... yikes), or a slot named P without predicate option...) and didn't encounter this
14:42:30
Bike
oh yeah, think we hit that building sbcl with clasp. some destruct assuming a nil default
14:45:18
Bike
and yeah, it's different from ordinary lambda lists, because defstrut is kind of bizarre
14:45:50
_death
right.. that's what I mean.. the standard says it's undefined (as well as slots without initforms).. that's why I consider it a quality of implementation issue
14:48:50
_death
I had to go through some of my code (not yet all..) and fix the defstruct slot specs
14:56:36
_death
stassats: I mean in my subjective model of the language as I understand it.. since it's one more unnecessary twist I would've preferred to see a CDR document specifying NIL values, but obviously not everyone agrees
14:58:01
_death
stassats: I had (defstruct foo bar zot) and expected (foo-bar (make-foo)) to return NIL
14:59:01
_death
that's only by accident.. I also expected &aux to initialize to NIL, and it's not, so I've no guarantee that my code will work in the future
15:00:24
_death
that's why I would've been more comfortable with a CDR document specifying this behavior and implementators affirming compliance to it
15:13:00
_death
stassats: I had BOA constructors with &aux, but luckily they all initialized the slot (otherwise, there's not much point in &aux :).. I guess that's why I've not noticed this
15:30:59
_death
if &aux is almost never used that way, why is it important that &aux foo has the foo slot unbound or set to 0
15:47:59
_death
I understand it's more efficient to do nothing, but it's also more surprising.. and if it rarely happens, is the concern about efficiency justified?