Re: [NSE] Shared Script Environments for Threads & Universal Awareness

[jah <jah () zadkiel plus com>]

On 01/07/2008 20:31, Kris Katterjohn wrote:
> Patrick Donnelly wrote:
> > On Mon, Jun 30, 2008 at 6:18 PM, jah <jah () zadkiel plus com> wrote:
> > > > Since we're using this nomenclature for script-specific information,
> > > > how about
> > > > making a global _R the registry interface?  It gets pretty ugly
> sometimes
> > > > trying to deal with some arguments, e.g.:
> > > >
> > > > nmap.registry.args.anonFTP.pass
> > > I'm for _R too!
> > > whois.nse has:
> > >
> > >    nmap.registry.whois.cache[host.ip].data
> > >
> > > which has to be writeable from all threads so cannot be copied into a
> > > local variable with a shorter name.
> > >
> > >    _R.cache[host.ip].data
> > >
> > > would be much nicer...
> > This can and should be solved by local variables.
>
> > local registry = nmap.registry;
> > local args = registry.args;
>
>
> That's like what I did for zoneTrans, and my point is that it's pretty
> lame
> that a bunch of scripts will have to do the exact same steps when the
> solution
> can be built-in somehow.  Like I said, I'm not pulling for any individual
> change (as much as I like the simple _R), but surely something can be done
> without requiring the scripts to handle the workaround for excess
> typing and
> what is IMO ugliness.
I should have said so more accurately, but in the example I gave, the
value is a shared one and that value should be read/writeable by any
thread.  That is, If thread A writes to it and thread B reads it, B sees
what A wrote and vice versa.  Unless I'm mistaken (and I'm going to feel
pretty silly if I am), copying some part of the registry to a local
variable removes this ability.  I thought that the whole point of
nmap.registry is to allow data to be shared between scripts and, after
recent changes, is now the only way to share dynamic data between
threads of the same script.
I've not missed something fundamental have I?

Regards,

jah



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org