I've been compiling with:
```
set -lx cflags '-std=c99 -Werror=pedantic -pedantic-errors'
```
But compilation would fail with the following:
```
cont.c:296:90: error: format specifies type 'void *' but the argument has type 'struct fiber_pool_stack *' [-Werror,-Wformat-pedantic]
if (DEBUG) fprintf(stderr, "fiber_pool_stack_alloca(%p): %"PRIuSIZE"/%"PRIuSIZE"\n", stack, offset, stack->available);
~~ ^~~~~
cont.c:467:24: error: format specifies type 'void *' but the argument has type 'struct fiber_pool *' [-Werror,-Wformat-pedantic]
count, fiber_pool, fiber_pool->used, fiber_pool->count, size, fiber_pool->vm_stack_size);
^~~~~~~~~~
cont.c:588:83: error: format specifies type 'void *' but the argument has type 'struct fiber_pool_vacancy *' [-Werror,-Wformat-pedantic]
if (DEBUG) fprintf(stderr, "fiber_pool_stack_acquire: %p used=%"PRIuSIZE"\n", fiber_pool->vacancies, fiber_pool->used);
~~ ^~~~~~~~~~~~~~~~~~~~~
cont.c:736:76: error: format specifies type 'void *' but the argument has type 'rb_fiber_t *' (aka 'struct rb_fiber_struct *')
[-Werror,-Wformat-pedantic]
if (DEBUG) fprintf(stderr, "fiber_stack_release: %p, stack.base=%p\n", fiber, fiber->stack.base);
```
This commit just fixes the pedantic errors
The kw_splat flag is whether the original call passes keyword or not.
Some types of methods (e.g., bmethod and sym_proc) drops the
information. This change tries to propagate the flag to the final
callee, as far as I can.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_proc_new / rb_fiber_new, and applies RB_BLOCK_CALL_FUNC_ARGLIST
wherever necessary.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_ensure, which also revealed many arity / type mismatches.
https://github.com/ruby/ruby/pull/2170#issuecomment-489880700
Documentation is for those who don't know, remember, or understand (to any degree) the language, it should attempt to be clear above all other things. The example given is needlessly unclear because if you use a block it's common for arguments to be reused on every entry to the block. In Fiber's case this is not so.
First time round 10 goes in, 12 comes out.
Second time round 14 goes in, 14 comes out… was that because 14 is 12 + 2 or because it's "the return value of the call to Fiber.yield". It's the latter because it says so but why does the example need to make anyone think the former?
Using different numbers makes it immediately clear what's happening whether the description is there or not.
Renaming this function. "No pin" leaks some implementation details. We
just want users to know that if they mark this object, the reference may
move and they'll need to update the reference accordingly.
After calling `fiber_pool_vacancy_reset`, `vacancy->stack` and `stack` are
no longer in sync. Therefore, `fiber_pool_stack_free(&vacancy->stack)` can
do the wrong thing and clobber the vacancy data.
Additionally, when testing using VM_CHECK_MODE > 0, use MADV_DONTNEED if
possible, to catch issues w.r.t. clobbered vacancy data earlier.
fiber->cont.saved_ec.cfp should be initialized by NULL
because no vm_stack is allocated. However, cont_init()
captures current Fiber's cfp for continuation, so it should
only initialize fibers.
`cont_init` didn't initialize `cont->saved_ec.cfp`. Calling `cont_mark`
would result in an invalid `cfp` in `rb_execution_context_mark`. Because
fibers lazy-initialize the stack, fibers that are created but not resumed
could cause this problem to occur.
If `mmap` fails to allocate memory, try half the size, and so on.
Limit FIBER_POOL_ALLOCATION_MAXIMUM_SIZE to 1024 stacks. In typical
configurations this limits the memory mapped region to ~128MB per
allocation.
We use COROUTINE_LIMITED_ADDRESS_SPACE to select platforms where address
space is 32-bits or less. Fiber pool implementation enables more book
keeping, and reduces upper limits, in order to minimise address space
utilisation.
`madvise(free)` and similar operations are good because they avoid swap
usage by clearing the dirty bit on memory pages which are mapped but no
longer needed. However, there is some performance penalty if there is no
memory pressure. Therefore, we do it by default, but it can be avoided.
On 32-bit platforms, expanding the fiber pool by a large amount may fail,
even if a smaller amount may succeed. We limit the maximum size of a single
allocation to maximise the number of fibers that can be allocated.
Additionally, we implement the book-keeping required to free allocations
when their usage falls to zero.
Replace previous stack cache with fiber pool cache. The fiber pool
allocates many stacks in a single memory region. Stack allocation
becomes O(log N) and fiber creation is amortized O(1). Around 10x
performance improvement was measured in micro-benchmarks.
During fork, it's possible that threads with root fibers are terminated,
but fiber state is not updated. `fiber_verify` will subsequently fail. We
forcefully enter the FIBER_TERMINATED state when terminating the root
fiber.
If `vm_stack` is left dangling in a forked process, the gc attempts to scan
it, but it is invalid and will cause a segfault. Therefore, we clear it
before forking.
In order to simplify this, `rb_ec_clear_vm_stack` was introduced.
