Get UVManager runing on the same capability.

Get MVar from blocking table with given slot.

Poke a prepared buffer and size into loop data under given slot.

NOTE, this action is not protected with 'withUVManager_ for effcient reason, you should merge this action with other uv action and put them together inside a 'withUVManager_ or 'withUVManager\''. for example:

   ...
   withUVManager_ uvm $ do
       pokeBufferTable uvm slot buf len
       uvReadStart handle
   ...

Lock an uv mananger, so that we can safely mutate its uv_loop's state.

libuv is not thread safe, use this function to perform any action which will mutate uv_loop's state.

Lock an uv mananger, so that we can safely mutate its uv_loop's state.

Some action did not request uv_loop pointer explicitly, but will mutate uv_loop underhood, for example: uv_read_start. These actions have to be protected by locking the uv_loop.

In fact most of the libuv's functions are not thread safe, so watch out!

Run a libuv FFI to get a UVSlotUnSafe (which may exceed block table size), resize the block table in that case, so that the returned slot always has an accompanying MVar in block table.

Always use this function to turn an UVSlotUnsafe into UVSlot, so that the block table size synchronize with libuv side's slot table.

Exception safe uv request helper

This helper will run a libuv's async function, which will return a libuv side's slot, then we will accommodate a MVar in block table and wait on that MVar, until the async function finished or an exception is received, in later case we will call cancelUVReq to cancel the on-going async function with best efforts,

Same with withUVRequest but disgard the result.

Same with withUVRequest but apply an convert function to result.

The convert function have all access to the returned value including negative ones, it's convert funtions's responsiblity to throw an exception if appropriate.

Same with withUVRequest, but will also run an extra cleanup function if async exception hit this thread but the async action is already successfully performed, e.g. release result memory.

Safely lock an uv manager and perform uv_handle initialization.

Initialization an UV stream usually take two step:

• allocate an uv_stream struct with proper size
• lock a particular uv_loop from a uv manager, and perform custom initialization, such as uv_tcp_init.

And this is what initUVStream do, all you need to do is to provide the manager you want to hook the handle onto(usually the one on the same capability, i.e. the one obtained by getUVManager), and provide a custom initialization function (which should throw an exception if failed).

A haskell data type wrap an uv_stream_t inside

UVStream DO NOT provide thread safety! Use UVStream concurrently in multiple threads will lead to undefined behavior.

Fork a new GHC thread with active load-balancing.

Using libuv based IO solution has a disadvantage that file handlers are bound to certain uv_loop, thus certain uv mananger/capability. Worker threads that migrate to other capability will lead contention since various APIs here is protected by manager's lock, this makes GHC's work-stealing strategy unsuitable for certain workload, such as a webserver. we solve this problem with simple round-robin load-balancing: forkBa will automatically distribute new threads to all capabilities in round-robin manner. Thus its name forkBa(lance).