Thoughts on v2

[JodiTheTigger]

Change to a malloc callback system

Why?

• I want to remove all my OS specific guard page code, makes sewing more OS agnostic.
• You don't need to malloc the entire fiber stack space up front
• You only need to call sew_it once
• Makes moving to a multiple stack size model easier
• Don't need to manage fiber stack memory anymore
• Easier to tie into alternative memory management systems of the user
• remove #include <malloc.h>

details

• Need to call malloc callback for each new fiber, passing in the stack size wanted
• now need to call free callback
• need to check for out of memory and handle in a sane way
• remove guard page code

cons

• API is now more complex
• no more guard pages

Non-blocking job queuing (single thread)

Why?

• Blocking due to some hard to determine reason is a crappy API
• Gives user more power to decide what to do
• I hate blocking APIs

details

• how do I deal with sew_stitches_and_wait and sew_stitches?
• TODO!

cons

• Makes API more complex, you need to be able to handle when jobs queued != jobs sent

multiple stack API

Why?

• To match the naughty dog fiber API feature set
• To call stack heavy library code

details

• Supply stack size either per job, or per submit (preferred)
• Need to validate stack sizes at submit and fail in an intelligent way
• Need to deal with out of memory when we pop the queue and try to malloc the fiber
• Add another API entry for default jobs which and use a default stack size (set at init) instead

cons

• Makes the API more complex. Now you need to fill in stack size

Single file header

Why?

• Easier to copy, manage and include in projects
• Compiles faster
• It's pretty much a single file lib anyway, except for the asm bits.

details

• Single license please (needs to be boost to match asm license)
• File will contain asm for many platforms
• Will need to be compiled twice, once for C/C++, and once for asm

cons

• will have asm for OSs you don't care about - file is larger
• single file header libs trip up code highlighting and browsing in IDEs

Simple Sewing API

Why?

• With the malloc changes the API is hard to just pickup and run. Too much boilerplate needed.
• I don't wanna deal with malloc, guard pages, stack size, etcetc.
• For a simple hello world example
• Shows one way to deal with not being able to queue all jobs on a single thread
• keeps the main sewing lib malloc free, by using it here instead
• keeps OS specific guard page stuff out of the main lib, puts example code here instead

details

• It should also be useable as a tutorial as well
• supply malloc and free callbacks, with automatic guard page for debug builds
• defaults for everything
• assert happy
• Optionally compiled in the single header file

Implement the Windows fiber API (but allow specify fiber memory)

Why?

• Simplifies the API even more
• No need to supply a main function callback to start the threading system, just ConvertThreadToFiber
• Shutdown code is much simpler, just call the equivalent to ConvertFiberToThread
• Drop in replacement to windows Fiber api, makes porting to other OS easier
• If I end up writing my own f_context asm, I can decide on the license instead of boost license.

details

• I have to write convert to fiber ASM for all supported platforms, as boost doesn't have a direct equivalent
• Need to test the ASM

cons

• Ugh, this just takes time, and having to learn asm for different platforms, as well as stdcall apis etc.

Make external trigger API impossible to create leaks

Why?

• Current API means it's easy to make leaks and undefined behaviour, which will be hard to track down
• Good APIs are easy to use correctly, hard to use badly

details

• Use a different type for an external trigger, as opposed to a normal wait chain