Still plenty of unimplemented features, but the compiler already runs.
Io.Dispatch: introduce grand central dispatch io impl #31198
I missed that the types were `pub`.
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 @@
constrc=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):
Huh, interesting, so it still uses fibers created independently from libdispatch?
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.
Also kqueue IIRC is implemented on top of GCD so it's a similiar situation to kernel32 vs ntdll
I believe it's the other way around, GCD is implemented on top of kqueue.
No due date set.
No dependencies set.
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?