Applications that choose pointer callbacks throughout a build may want to use the familiar tx_thread_create and tx_timer_create names. The additive APIs proposed in #771 provide this behavior per call; #413 documents why changing the existing signatures by default is disruptive.
I propose evaluating an optional source-level mode that maps those names to the new pointer APIs. It would use the same kernel implementation and ABI as the additive APIs, leave ULONG at 32 bits, and require matching callback signatures. I want the design to identify which existing callers, including component code that explicitly casts pointers to ULONG, would need edits or diagnostics.
I would leave delivery timing TBD. We should decide whether the naming convenience justifies a build-wide source contract after the additive APIs and a migration example are available.
Applications that choose pointer callbacks throughout a build may want to use the familiar
tx_thread_createandtx_timer_createnames. The additive APIs proposed in #771 provide this behavior per call; #413 documents why changing the existing signatures by default is disruptive.I propose evaluating an optional source-level mode that maps those names to the new pointer APIs. It would use the same kernel implementation and ABI as the additive APIs, leave
ULONGat 32 bits, and require matching callback signatures. I want the design to identify which existing callers, including component code that explicitly casts pointers toULONG, would need edits or diagnostics.I would leave delivery timing TBD. We should decide whether the naming convenience justifies a build-wide source contract after the additive APIs and a migration example are available.