Re: [NSE] Thread-safety questions

[nnposter () users sourceforge net]

Patrick Donnelly wrote:
> On Tue, Jul 30, 2013 at 8:27 PM, <nnposter () users sourceforge net> wrote:
> > 1. Socket use across threads
> >
> > Recently I ran into an issue of nmap failing to return from
> > socket:connect() so I posed a question to the mailing list about
> > whether sockets can be used across threads. Patrick Donnelly answered
> > that this is indeed prohibited. Could somebody please point out where
> > it is documented? (I do try to RTFM but I have somehow missed it and
> > I wonder if there are other similar constraints.)
>
> I don't think it's documented anywhere. Libraries like the socket
> library (nse_nsock.cc) need to know the "owner" of a resource for
> socket locks. What it means to transfer ownership to another thread is
> an open question. I don't really feel it's worth answering.
>
> We can expand the documentation I suppose to be more clear about this.

Great. All I am looking for is some basic information about what NSE
functionality is not thread-safe.


> > 2. Behavior of stdnse.new_thread()
> >
> > Given the collaborative threading model, is a new thread created with
> > stdnse.new_thread() guaranteed not to start running until the parent
> > thread explicitly or implicitly yields (through yield(),
>
> A call to Lua's yield will never validly release control to NSE. NSE
> would not know how to resume the script.
>
> > sleep(),
> > socket I/Os, mutexes, etc.)?
>
> For the current implementation, the answer is yes. I don't see a
> reason why a guarantee needs to be made. No guarantee exists in POSIX
> threading (from which we draw many concepts).

I am asking about this assurance because I found some current nselib
code that depends on it. Specifically, it uses new_thread() to spawn
worker threads and only then it initializes data structures that the
workers consume. I was therefore wondering if this is a race condition
bug or not.

> > If the answer "Yes, always", could again
> > somebody please point out the relevant documentation? (Source code does
> > not count ;-)
>
> We can expand the documentation here too. Would you like to take a
> stab at it? :)

This is better left to the folks that actually wrote the functionality,
no?


Cheers,
nnposter
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/