Coverage compiler and linker flags are used only when (1) in debug build
and (2) with ENABLE_COVERAGE set to 1. Besides, because OS X's libtool
is unable to understand '--coverage', this linker flag is only used
genrating executable targets. Also, using 'link_settings' to specify
linker options and separate instructions for OSX and Linux.
The last map object to get destroyed will also destroy
the RunLoop (which will also destroy the AsyncTask).
This will clear any reference to the Node default main
loop and let it close.
Downside is that we need to make sure we are always calling
`map.release()`.
The run loop will be kept alive because it has an `AsyncTask`. We
also can simple stop the loop with `uv_stop()`.
The `RunLoop` is still gonna be the last object to be destroyed
because it is the first object to be created in the thread, so
by design it won't outlive `Timer`s and `AsyncTask`s.
This patch won't change the current behavior, will just make
the code simpler.
The lock is in place to enforce that `async` is not accessed if the request has been, cancelled. Therefore it's not necessary to hold the lock beyond setting cancelled to true, and in fact it's unsafe to so: if this is the last remaining shared reference, `delete this` will destroy the mutex. If the lock was held, it would then be orphaned.
People are used to dragging frameworks into the Linked Frameworks and Libraries section, but the SDK only works when embedded inside the application.
Fixes#4011.
If we don't do this, we can activate a request twice.
The issue here is that we use memory address as the 'key'. So if
we destroy a request, another request might take the same memory
address, or the same 'key'.
The entry at 'pendingRequests' survives the 'cancel()' and is
ultimatelly removed at 'activatePendingRequest()'. This is fine
unless a request is created using the same 'key' before we call
'activatePendingRequest()'.
The check if the request was canceled at 'activatePendingRequest()'
will be no longer valid, activating the request. At the same time
the request will be activated again by the task scheduled at the
constructor of the 'OnlineFileRequestImpl' class.
