3 ms·

I'd really like to understand how live reloading works a bit better, especially when editing variables that some running thread depends upon. Is there an overal

by gaze 4y ago

I'd really like to understand how live reloading works a bit better, especially when editing variables that some running thread depends upon. Is there an overall strategy here? Do I implement locking around variables that I intend to play with at runtime?

User23 4y ago
I don’t believe the Common Lisp specification says anything about threads. For example here[1] is the relevant section of the SBCL manual. As you can see it’s quite low level. If you’re using those primitives then yes you’ll have to manage barriers, synchronization, use atomic operations, or otherwise maintain sanity. The REPL (or SWANK) thread is just another thread. Edit: I should add that the usual pattern is Bordeaux threads or some other higher level thing. [1] http://www.sbcl.org/manual/index.html#Threading http://www.sbcl.org/manual/index.html#Threading
whartung 4y ago
All of the contention issues that we've had for ages across all platforms exist in CL. Loading and compiling new code isn't any different than two separate threads calling setq on the same element at the same time. The reality, though, is that the vast majority of the time when this is done, the system is idle. If you live update your server that's serving 1000 connections and isn't specifically coded to handle this potential event, then, for sure, there can be trouble. But if you're hot reloading your dev server, with an idle connection, then you're likely to have fewer problems. However, there's the potential impact of captured state that is not properly refreshed. For example, if you have some long running state that, say, captured a function via #'my-func, then that routine has, indeed, captured the pointer to the routine. But when you redefined it, the symbol (i.e. my-func) is now pointing to the new code, while your existing state is pointing to the old code. Any code that uses the symbol to call the routine will update automatically, but anything that does not, is stuck with stale data. And that rock potentially sends different ripples through the still pond of your running image. Just something to be aware of. It's a great feature, just need to be aware of what's going on when you do it. Most of the time, it's a non-issue.
- deleted 4y ago
  [deleted]
aidenn0 4y ago
With the threading model of most CL implementations, you really only need locking if you need to change two (or more) places and have the update appear atomic, or if you are doing a read/modify/write. But you would already need such infrastructure in place if you were going to modify them in you program as well.

by gaze 4y ago

User23 4y ago

I don’t believe the Common Lisp specification says anything about threads. For example here[1] is the relevant section of the SBCL manual. As you can see it’s quite low level. If you’re using those primitives then yes you’ll have to manage barriers, synchronization, use atomic operations, or otherwise maintain sanity. The REPL (or SWANK) thread is just another thread. Edit: I should add that the usual pattern is Bordeaux threads or some other higher level thing. [1] http://www.sbcl.org/manual/index.html#Threading http://www.sbcl.org/manual/index.html#Threading

whartung 4y ago

All of the contention issues that we've had for ages across all platforms exist in CL. Loading and compiling new code isn't any different than two separate threads calling setq on the same element at the same time. The reality, though, is that the vast majority of the time when this is done, the system is idle. If you live update your server that's serving 1000 connections and isn't specifically coded to handle this potential event, then, for sure, there can be trouble. But if you're hot reloading your dev server, with an idle connection, then you're likely to have fewer problems. However, there's the potential impact of captured state that is not properly refreshed. For example, if you have some long running state that, say, captured a function via #'my-func, then that routine has, indeed, captured the pointer to the routine. But when you redefined it, the symbol (i.e. my-func) is now pointing to the new code, while your existing state is pointing to the old code. Any code that uses the symbol to call the routine will update automatically, but anything that does not, is stuck with stale data. And that rock potentially sends different ripples through the still pond of your running image. Just something to be aware of. It's a great feature, just need to be aware of what's going on when you do it. Most of the time, it's a non-issue.

deleted 4y ago
[deleted]

aidenn0 4y ago

With the threading model of most CL implementations, you really only need locking if you need to change two (or more) places and have the update appear atomic, or if you are doing a read/modify/write. But you would already need such infrastructure in place if you were going to modify them in you program as well.