mailing list archives
Re: [NSE] Thread-safety questions
From: nnposter () users sourceforge net
Date: Wed, 31 Jul 2013 17:52:25 +0000
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.
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,
Sent through the dev mailing list
Archived at http://seclists.org/nmap-dev/