View previous topic :: View next topic |
Author |
Message |
JarrettBillingsley
Joined: 20 Jun 2006 Posts: 457 Location: Pennsylvania!
|
Posted: Tue Feb 12, 2008 9:54 pm Post subject: Module reloading |
|
|
I've got basic module reloading implemented in MiniD 2. It was actually quite a bit easier than I expected
Anyway what some of you were suggesting/hoping for was that when a module was reloaded, the objects/functions in it would seamlessly replace those that were in the module before. Notably any objects declared in the module, when reloaded, would work themselves into any inheritance hierarchies that they were a part of, so that you could, say, reload a module that had an object definition and suddenly all instances of that object would have the updated code.
While this is a pretty awesome thing to offer, the thing is I can't see how to implement this in any kind of efficient manner in a dynamic language. The problem is that any code anywhere can squirrel away a reference to an object/function/whatever in some other location, maybe even one that's not accessible by MiniD code (stored in some native data structure). This means that basically, in order to seamlessly replace an object, it'd have to keep track of every single reference to it. This is obviously not a practical solution.
Another possibility would be to doubly-indirect every reference type so that only one location - the reference, to which everything else points - would have to be changed. While this solves the problem kind of nicely, it introduces an extra layer of complexity and slowdown, something I don't want to force on everybody if this feature isn't going to be used that much. (although: if I implement it, will its mere existence cause people to use it? )
This just feels like another one of those features that would be much, much easier to implement in a statically-typed language.
If anyone has any thoughts, suggestions, alternatives etc. I'd be more than happy to hear them |
|
Back to top |
|
|
Ligustah
Joined: 21 Oct 2007 Posts: 45 Location: Berlin, Germany
|
Posted: Sun Feb 17, 2008 10:33 am Post subject: |
|
|
JarrettBillingsley wrote: | if I implement it, will its mere existence cause people to use it? |
Indeed it is not really useful, when a program is just run once, however it is - IMHO - quite important considering server applications, that could possibly use MiniD. Having to reload the whole Context just because of a little module that changed and has to be reloaded, wouldn't be very nice, would it ?
So i think, if it's not too difficult and if it is not slowing down everything too much it is worth of being implemented.
Ligustah |
|
Back to top |
|
|
JarrettBillingsley
Joined: 20 Jun 2006 Posts: 457 Location: Pennsylvania!
|
Posted: Sun Feb 17, 2008 2:37 pm Post subject: |
|
|
Quote: | if it's not too difficult and if it is not slowing down everything too much it is worth of being implemented |
That's the thing -- it is difficult to implement and chances are that it would slow everything down, although of course to test that I'd first have to implement it.
Do you have any other ideas? Constraints etc. that would make this problem easier to solve? |
|
Back to top |
|
|
r.lph50
Joined: 27 Nov 2006 Posts: 21 Location: New Zealand
|
Posted: Mon Feb 18, 2008 12:00 am Post subject: |
|
|
I'd always imagined that if it a server application, you would handle new connections with a new MDContext. Any existing connections could be eased off the old MDContext. Problem then becomes is it possible to migrate the state held by MDState instance..
I'm probably totally off-base.
(I imagine an event driven server would have a main MDContext per 'application' and some way of generating a MDState instance per connection with the applications main function - must getting around to trying this with libev/tango). |
|
Back to top |
|
|
JarrettBillingsley
Joined: 20 Jun 2006 Posts: 457 Location: Pennsylvania!
|
Posted: Mon Feb 18, 2008 4:35 pm Post subject: |
|
|
Quote: | I'd always imagined that if it a server application, you would handle new connections with a new MDContext. |
The problem with that approach is that MDContext is not exactly.. lightweight. Each time you create a context, its global namespace has to be created and loaded with symbols. I mean, you might be able to hack around that and assign a new context's globals to an old one's, but that's kind of defeating the purpose.
Closer to your parenthesized idea, this seems more like a job for spawning new MDStates, i.e. the equivalent of spawning a new thread to handle a connection. The language doesn't provide any sort of scheduling mechanism to run these states, but it provides the primitives to do so (yield and resume).
What I'm wondering is if you have some sort of use case where you wouldn't be able to just spawn a new state. I mean, are there synchronization issues? Would you need the equivalent of thread-local storage?
(bam! tls:
Code: | local t = {};
local maint = {};
global function getTLS(name)
{
local thread = currentThread();
if(thread is null)
return maint[name];
else
{
local tab = t[thread];
if(tab is null)
t[thread] = {};
return t[thread][name];
}
}
global function setTLS(name, val)
{
local thread = currentThread();
if(thread is null)
maint[name] = val;
else
{
local tab = t[thread];
if(tab is null)
t[thread] = {};
t[thread][name] = val;
}
} |
funtimes.) |
|
Back to top |
|
|
r.lph50
Joined: 27 Nov 2006 Posts: 21 Location: New Zealand
|
Posted: Mon Feb 18, 2008 4:49 pm Post subject: |
|
|
Oh I meant any new connections after modules have been reloaded would use the new MDContext. So its a per application context, and if the application gets modified or upgraded you'd create a new context and transition over to it. Multiple connections share an application. So, yes, each connection gets it's own MDState sharing the same MDContext. |
|
Back to top |
|
|
JarrettBillingsley
Joined: 20 Jun 2006 Posts: 457 Location: Pennsylvania!
|
Posted: Mon Feb 18, 2008 10:17 pm Post subject: |
|
|
Oh, I see what you were getting at now |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|