swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Module_activity_ [Swarm 1.4.1]


From: Gary Polhill
Subject: Module_activity_ [Swarm 1.4.1]
Date: Tue, 21 Nov 2000 18:09:17 +0000

Hi,

Sorry, we're still working on Swarm 1.4.1 here -- will upgrade soon!!
For now, however, I've got an interesting bug that I can work around but
not fix. I use protocols a lot in the model I'm developing to enable
folks to plug in different objects to do various jobs. For example, I
have a series of Strategy protocol objects that users can choose from
(in the configuration files) to give the agents different behaviour.
It also means they can write their own Strategy objects and compile them
in with ease. What I want to be able to do is make a list of all classes
that follow the Strategy protocol.

Here's how I've done it:

First I use the objc-api function objc_next_class() to build a list of
classes in the system. I then copy this list into a Swarm list. (For
some reason making any call to a method whilst looping through the
objc_next_class() loop messes up the loop.)

static ClassInfo *info;

@implementation ClassInfo

+(void)initialise: (id <Zone>)aZone {
  void *enum_state;
  struct list_of_classes {
    Class theClass;
    struct list_of_classes *next;
  } *l, *m, *n;
  Class aClass;
  struct objc_protocol_list *pl;

  info = [super create: aZone];

  /* Loop through all the classes. For some reason this is messed up if you
     make any method calls during the loop. So, first we build the list using
     conventional memory. Then we'll put it into a swarm list. */
  n = l = NULL;
  while((aClass = objc_next_class(&enum_state)) != Nil) {
    m = n;
    n = (struct list_of_classes *)xmalloc(sizeof(struct list_of_classes));
    if(l == NULL) l = n;
    if(n == NULL) {
      fprintf(stderr, "Memory allocation error\n");
      exit(1);
    }
    n->theClass = aClass;
    n->next = NULL;
    if(m != NULL) m->next = n;
  }

  /* Right, now we build the swarm list. The Class type is a pointer, so it's
     OK to treat it like an id. Whilst we build the Swarm list, we destroy
     the one we've just created. Thus all memory for the object sits in the
     Swarm Zone, and the object can be destroyed when the Zone is destroyed. */

  info->cl = [List create: aZone];

  m = NULL;
  for(n = l; n != NULL; n = n->next) {
    if(m != NULL) free(m);
    if(n->theClass != Nil) [info->cl addFirst: n->theClass];
    m = n;
  }
  if(m != NULL) free(m);
}

// When I want to know all the classes that follow a particular protocol,
// I search through the Swarm List using the conformsTo: method:

+(void)getClassesForProtocol: (Protocol *)p inList: (id <List>)l {
  id <Index>i = [info->cl begin: scratchZone];
  Class c;

  for(c = (Class)[i next];
      [i getLoc] == Member;
      c = (Class)[i next]) {
    if([c conformsTo: p]) [l addFirst: c];
  }

  [i drop];

}

@end

For some odd reason, I get a segfault when c in the above loop is
Module_activity_ -- I've spent ages with gdb trying to find out what
is going wrong. If I stop at the if([c conformsTo: p] ... line, and
step 100000 times, I still don't segfault. If I do a next instead of
a step, I get the segfault. I can't see through what it is trying to
do because I haven't got the objc source code available, but it seems
to be looping round calling [Module_activity_ class] and
[Module_activity_ conformsTo:] My guess is after a while it does this
enough to mess up the internals, and segfaults. A backtrace is not
particularly helpful.


The creation of the Module_activity_ class seems to be done at runtime,
via some mysterious trickery in defobj/Program.m. I can work around the
problem without too much difficulty -- what I wonder is if the problem
with Module_activity_ is down to some obscure bug in the Swarm code
that you might want to know about (even though you're on Swarm 2.1.1)
-- I don't get the problem with the Module_collections_ class, for
example.

If you can spare a mo to offer a little enlightenment for this rather
obscure problem, I'd be grateful, but I understand if you can't...

Thanks

Gary

-- 

Macaulay Land Use Research Institute, Craigiebuckler, Aberdeen. AB15 8QH
Tel: +44 (0) 1224 318611               Email: address@hidden

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]