Re: [NSE] need to get waiting threads to resume after a thread having mutex dies

[jah <jah () zadkiel plus com>]

On 08/08/2008 00:58, Patrick Donnelly wrote:
> Hi Jah,
>   
> The basic idea of a mutex (in a multi threading sense) is to provide
> data consistency, coherency, and safety. If a thread dies, there is no
> way for another thread to know what state the data is left in.
> Therefore, allowing another thread to lock on the mutex and manipulate
> the data will only lead to very odd and seemingly "impossible" bugs.
> While generally these mutexes will not be used to protect against
> asynchronous data manipulation, they could be; so it is best to
> maintain a policy of "you break it, you get to keep both pieces".
>   
That makes sense.  I should have mentioned the behaviour seen when this
happens.  Nmap gets into an infinite while() loop inside nse_main.cc and
I reckon this, at least, should be avoided.  Using --script-trace and
redirection you can generate GB files in very short order, as I found
once after returning from making a cuppa!
Fine if the script scan is aborted, better if only that script is affected.
> It would be best for you to be certain that any errors are caught so
> that your thread does necessary cleanup, such as unlocking a mutex
> (and restoring the state of any data it protects). I assume you are
> familiar with pcall[1], which will allow you to catch any errors that
> are thrown. I also suggest that you always have your script prevent
> itself from dying in an uncontrolled way (in that, NSE has to "clean
> up after it"). A script that often errors over things like "Lua stack
> overflow" or "attempt to concatenate a nil value" are not something a
> user likely wants to see, even if it is rare.
>
> [1] http://www.lua.org/manual/5.1/manual.html#pdf-pcall
I wasn't familiar with pcall, I am now, so thank you.  It'll be trivial
to add this protection to whois and even though I'm pretty confident
that it won't get caught out like this (again), I'll err on the side of
caution and add it.

Cheers,

jah

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