freenode/#lisp - IRC Chatlog
Search
5:05:18
Guthur
Is there a CL implementation that allows setting processor affinity for a given thread?
7:01:28
clintm
I've been rolling around a desire I've had for a CL that runs like Pharo and Squeak. For instance, by default it's image driven, has a common gui, the code for and state of which is contained in an image, but can also run headless on a server. Are there any projects alive or dead that have tried to do this? I'm not looking to write yet another lisp, but rather add to or, worst case, fork from another.
7:08:49
mrcom
minion: memo for drmeister: Deadlocking on GF memoization, invalidating, or using memoized? Are you using lockless structures, or locking in the fast path?
7:47:04
beach
mrcom: drmeister is very likely asleep. He had some race conditions, so he added some locks, and now he has deadlocks. I think that there has not been any sufficient consideration of all the possible scenarios that can happen when classes, generic functions, and instances are being updated. I explain the lock-free data structure I am planning to use to update the call history in SICL, and he thought that was a good idea for Clasp as
7:50:41
beach
mrcom: The discriminating function must be computed from the call history essentially without using any generic functions. The call history can not simply be invalidated, because that would create metastability problems for specified generic functions.
7:51:55
beach
The only compilation that should be done in most situations is to create the discriminating function from the call history.
7:53:56
beach
In SICL, I instead plan to have a working compiler in a separate environment so that there is no attempt to use the same compiler to create discriminating functions as the one that is being modified.
7:54:50
beach
Even adding a method should not require the compiler. The method function should be compiled outside any locks.
7:55:30
beach
But, again, I don't think there has been sufficient effort to imagine every possible scenario and how each one should be handled.
7:55:40
mrcom
You're still going to need to lock stuff, aren't you? e.g., avoiding simultaneous changes to structs.
7:57:02
beach
Like I explained to drmeister, there are two possible results of synchronization problems. 1. It violates the integrity of the system, and 2. It just gives the "wrong" result.
7:57:33
beach
Number 2 can not always be avoided because it has to do with the kind of code that the application writer wrote.
7:58:03
beach
So for 2, one has to think hard about what is acceptable to the application writer, and what the system can handle.
8:00:55
beach
In SICL, I plan to cache the result of looking up the value of a special variable in the case where there is no tight loop and no call to an external function. It is "consistent" in that there is no experiment that the application programmer can conduct to determine whether the thread was just very fast.
8:04:28
beach
I don't know. It was just wrong to him. The special variable should be accessed every time because that's what the semantics dictate.
8:06:42
mrcom
Might even if it's on the stack, using anonymous registers in the underlying physical engine.
8:07:34
beach
Anyway, I think drmeister has some work to do. And it is not as simple as invalidate or memoize.
8:08:00
beach
From #clasp: Here is an interesting scenario: Suppose some class C is updated. Now, all existing instances of C are obsolete. Suppose that two different threads T1 and T2 use the same obsolete instance (say O) as arguments to perhaps two different generic functions F1 and F2 respectively. Is it possible that the discriminating function of F1 has been updated, but that of F2 has not?
8:08:16
beach
If so, the following could happen: T2 runs the discriminating function, and the result is an accessor that goes directly to some slot, but then T2 is delayed, and T1 executes. The discriminating function of F1 fails, so T1 detects that O is obsolete. It now alters the contents of the slots of O. Now, T2 executes again and accesses the wrong slot of O, perhaps even outside of O.
8:11:35
mrcom
The simple, provable correct way might be to globally invalidate all GFs whenever any class changes, and put a global lock around compilation of any DF. How often do classes change?
8:21:31
beach
mrcom: Look in the AMOP book. It will create metastability problems for specified generic functions.
8:22:43
beach
For example, if you remove from the cache entries on specified generic functions that specialize to specified classes, then you will never recover.
8:23:10
beach
Because there are so many specified generic functions that still need to work for specified classes in order to recover.
8:24:01
Fare
A tale of many nests https://fare.livejournal.com/189741.html My favorite small macro, macro modularity, and defining macros, in Common Lisp and in Scheme
8:25:29
Fare
beach: at some point, I'll want to pick your brain as to how best to add CLOS to Gerbil.
8:27:02
beach
Sure. Today is bad, though. I have lunch guests coming in 30 minutes and I still have cooking to do.
13:20:44
phoe_
Or should I use #.(format nil "something that uses ~#\Newline to create non-broken strings") ?