Io.Dispatch: introduce grand central dispatch io impl #31198
No reviewers
andrewrk
Labels
No labels
abi/f32
abi/ilp32
abi/n32
abi/sf
abi/x32
accepted
arch/1750a
arch/21k
arch/6502
arch/a29k
arch/aarch64
arch/alpha
arch/amdgcn
arch/arc
arch/arc32
arch/arc64
arch/arm
arch/avr
arch/avr32
arch/bfin
arch/bpf
arch/clipper
arch/colossus
arch/cr16
arch/cris
arch/csky
arch/dlx
arch/dsp16xx
arch/elxsi
arch/epiphany
arch/fr30
arch/frv
arch/h8300
arch/h8500
arch/hexagon
arch/hppa
arch/hppa64
arch/i370
arch/i860
arch/i960
arch/ia64
arch/ip2k
arch/kalimba
arch/kvx
arch/lanai
arch/lm32
arch/loongarch32
arch/loongarch64
arch/m32r
arch/m68k
arch/m88k
arch/maxq
arch/mcore
arch/metag
arch/microblaze
arch/mips
arch/mips64
arch/mmix
arch/mn10200
arch/mn10300
arch/moxie
arch/mrisc32
arch/msp430
arch/nds32
arch/nios2
arch/ns32k
arch/nvptx
arch/or1k
arch/pdp10
arch/pdp11
arch/pj
arch/powerpc
arch/powerpc64
arch/propeller
arch/riscv32
arch/riscv64
arch/rl78
arch/rx
arch/s390
arch/s390x
arch/sh
arch/sh64
arch/sparc
arch/sparc64
arch/spirv
arch/spu
arch/st200
arch/starcore
arch/tilegx
arch/tilepro
arch/tricore
arch/ts
arch/ubicom8
arch/v850
arch/vax
arch/vc4
arch/ve
arch/wasm
arch/we32k
arch/x86
arch/x86_64
arch/xcore
arch/xgate
arch/xstormy16
arch/xtensa
autodoc
backend/c
backend/llvm
backend/self-hosted
binutils
breaking
build system
debug info
docs
error message
frontend
fuzzing
incremental
lib/c
lib/compiler-rt
lib/cxx
lib/std
lib/tsan
lib/ubsan-rt
lib/unwind
linking
miscompilation
os/aix
os/android
os/bridgeos
os/contiki
os/dragonfly
os/driverkit
os/emscripten
os/freebsd
os/fuchsia
os/haiku
os/hermit
os/hurd
os/illumos
os/ios
os/kfreebsd
os/linux
os/maccatalyst
os/macos
os/managarm
os/netbsd
os/ohos
os/openbsd
os/plan9
os/redox
os/rtems
os/serenity
os/solaris
os/tvos
os/uefi
os/visionos
os/wali
os/wasi
os/watchos
os/windows
os/zos
proposal
release notes
testing
tier system
zig cc
zig fmt
bounty
bug
contributor-friendly
downstream
enhancement
infra
optimization
question
regression
upstream
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ziglang/zig!31198
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "dispatch"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Still plenty of unimplemented features, but the compiler already runs.
Huh, interesting, so it still uses fibers created independently from libdispatch? One thing I didn't figure out from reading the code is how does thread spawning work?
@ -0,0 +2770,4 @@const rc = c.getdirentries(dr.dir.handle, dents_buffer.ptr, dents_buffer.len, &header.seek);switch (c.errno(rc)) {.SUCCESS => break @intCast(rc),.INTR => {},no cancel checks?
Currently only mutex (not
Io.Mutex) and futex have intentionally designed cancellation, but select and group may accidentally work from being copied from a similar enough io impl.Don't forget to create followup issues to track unimplemented features, to invite contributors to help out!
@andrewrk wrote in #31198 (comment):
Otherwise libdispatch would create one thread per async, and you would just end up with a threaded impl with no thread limit and no interesting evented properties.
What's the benefit of libdispatch, compared to kqueue?
Recursive directory watching on macos already introduces a dependency on libdispatch, at which point your choices are to use an io impl based on libdispatch, or to have file watching behave like a blocking, synchronous syscall with respect to kqueue. If we knew the lower level abi of the fs event log service (I don't) and if it were stable (unlikely) we could connect it to a kqueue impl ourself.
Also kqueue IIRC is implemented on top of GCD so it's a similiar situation to kernel32 vs ntdll
DispatchSource is built on top of kqueue, and the most important feature of libdispatch, in my opinion, is its ability to dynamically spawn and retire pthreads through the lower-level pthread_workqueue API, which is integrated throughout Darwin system APIs such as XPC and Network.framework.
Ok I take it back, the protocol is dead simple and there is little room for misinterpretation.
I believe it's the other way around, GCD is implemented on top of kqueue.