Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: [NSE] Thread-safety questions
From: Patrick Donnelly <batrick () batbytes com>
Date: Wed, 31 Jul 2013 03:21:44 -0400

Apologies for previous mail, hit send early.

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.

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.

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).

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

Patrick Donnelly
Sent through the dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]