Re: [NSE] Thread-safety questions

[Patrick Donnelly <batrick () batbytes com>]

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.

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

> 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
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/