Websocket AsyncHandshake callback might starve go-routines trying to `ioc.Post()`

[sergiu128]

Within websocket/stream.go, the async handshake is done in another go-routine (no async dial for TCP nor TLS yet, so we "fake" it). If successful, the caller's callback is invoked by Posting it from the handshake goroutine in sonic's goroutine (and hence the caller's goroutine).

Within that callback we might be compute bound for a long time or just start reading from the socket, where all reads are immediate up to a constant limit. While the callback is running, the Post lock might be held for long enough to noticeably starve other go-routines that are Posting.

Unsure yet how to bypass this.

[EliasL15]

I’m not 100% sure this is the best approach, but I thought of a possible fix and opened a PR mainly for review: #163.

What I did:

• Swap posts under lock and dispatch callbacks outside the Post mutex.
• Reuse a runq buffer by swapping posts ↔ runq each wake to avoid allocations.
• Coalesce wakes: only write to the pipe/eventfd when transitioning from empty → non-empty.
• Make pending accounting atomic; batch-decrement after dispatch; Pending() uses atomic.LoadInt64.
• Add a panic guard around callbacks to keep the poller loop alive.

This should keep Post O(1) (append + wake), reduce contention, and prevent starvation when a callback is compute-heavy or drives immediate reads.

Would appreciate feedback on whether this direction makes sense or if there’s a cleaner way to handle it.