FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Module reloading

 
Post new topic   Reply to topic     Forum Index -> MiniD
View previous topic :: View next topic  
Author Message
JarrettBillingsley



Joined: 20 Jun 2006
Posts: 457
Location: Pennsylvania!

PostPosted: Tue Feb 12, 2008 9:54 pm    Post subject: Module reloading Reply with quote

I've got basic module reloading implemented in MiniD 2. It was actually quite a bit easier than I expected Neutral

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? Surprised)

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 Smile
Back to top
View user's profile Send private message
Ligustah



Joined: 21 Oct 2007
Posts: 45
Location: Berlin, Germany

PostPosted: Sun Feb 17, 2008 10:33 am    Post subject: Reply with quote

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
View user's profile Send private message
JarrettBillingsley



Joined: 20 Jun 2006
Posts: 457
Location: Pennsylvania!

PostPosted: Sun Feb 17, 2008 2:37 pm    Post subject: Reply with quote

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
View user's profile Send private message
r.lph50



Joined: 27 Nov 2006
Posts: 21
Location: New Zealand

PostPosted: Mon Feb 18, 2008 12:00 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
JarrettBillingsley



Joined: 20 Jun 2006
Posts: 457
Location: Pennsylvania!

PostPosted: Mon Feb 18, 2008 4:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
r.lph50



Joined: 27 Nov 2006
Posts: 21
Location: New Zealand

PostPosted: Mon Feb 18, 2008 4:49 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
JarrettBillingsley



Joined: 20 Jun 2006
Posts: 457
Location: Pennsylvania!

PostPosted: Mon Feb 18, 2008 10:17 pm    Post subject: Reply with quote

Oh, I see what you were getting at now Smile
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> MiniD All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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