Hi,
Although I really want to work on stuff like DCC and writing CTCP helper functions for coloring etc., I think I need to address technical problems first.
AFAICT, the current implementation will leak memory (ie won't be garbage collected correctly) if users and channels are not removed (using remove-user and remove-channel) before all references to a connection object are lost/broken. In such cases, although nothing refers to the connection object anymore, the channel may still contain user objects and the users will still hold channel objects in their channel lists. In other words: they won't be gc-able.
I'd like to change the library implementation to resolve this issue. It will have some API consequences.
The idea is that even though there may be a very large number of users, the number of channels will probably remain limited (several 10.000s max) and that several thousands of hash lookups are fast. [I never run the library with more than 20 channels...]
So, I'd like to bring back the one-way hierarchy in the library by eliminating the channels list on the user object, replacing it by a channels method which serves the same purpose, but dynamically collects the result.
Most user and channel operations will need a connection object to be passed in to function correcly though.
bye,
Erik.
On Tue, Mar 22, 2005 at 01:58:44PM +0100, Erik Huelsmann wrote:
AFAICT, the current implementation will leak memory (ie won't be garbage collected correctly) if users and channels are not removed (using remove-user and remove-channel) before all references to a connection object are lost/broken. In such cases, although nothing refers to the connection object anymore, the channel may still contain user objects and the users will still hold channel objects in their channel lists. In other words: they won't be gc-able.
Without knowing the internals of cl-irc...
If an object isn't reachable, it is garbage collected. Circular unreachable references are not a problem.
Zach
On Tue, Mar 22, 2005 at 01:58:44PM +0100, Erik Huelsmann wrote:
AFAICT, the current implementation will leak memory (ie won't be garbage collected correctly) if users and channels are not removed (using remove-user and remove-channel) before all references to a connection
object
are lost/broken. In such cases, although nothing refers to the
connection
object anymore, the channel may still contain user objects and the users will still hold channel objects in their channel lists. In other words:
they
won't be gc-able.
Without knowing the internals of cl-irc...
If an object isn't reachable, it is garbage collected. Circular unreachable references are not a problem.
Wow! That's far more sophisticated than I'm used from any self-memory-managing language. Can I count on that in any lisp implementation? (in other words, is that part of the standard?)
bye,
Erik.
On Tue, Mar 22, 2005 at 04:26:33PM +0100, Erik Huelsmann wrote:
Without knowing the internals of cl-irc...
If an object isn't reachable, it is garbage collected. Circular unreachable references are not a problem.
Wow! That's far more sophisticated than I'm used from any self-memory-managing language. Can I count on that in any lisp implementation? (in other words, is that part of the standard?)
Garbage collection is not part of the standard. However, I don't know of any Lisp that doesn't do GC, and all the Lisp GCs I know of are not reference counting GCs. Reference counting is a pretty bad (but easy, thus popular) strategy for memory management, since it can be slower than a real GC and it has the circularity problems you mention. Reference counting is a joke; Lisp GCs are usually serious.
Zach