Post 9yeghdIOC4689pvjfM by foxcpp@puppo.space
 (DIR) More posts by foxcpp@puppo.space
 (DIR) Post #9yeeQ4BVHaRyQoCnse by sir@cmpwn.com
       2020-08-30T17:18:56Z
       
       0 likes, 0 repeats
       
       If libuv or something similar were in the C stdlib (or POSIX), how would that change the way you use C? For the better? For the worse? No different?
       
 (DIR) Post #9yef0uiRRxuVmNBMJs by jasonscheirer@toot.jasonscheirer.com
       2020-08-30T17:24:27Z
       
       0 likes, 0 repeats
       
       @sir epoll *did* change that way I wrote C back when I was writing networked C ~15 years ago, but only slightly. If I’m writing lots of code that blocks on I/O it’s usually easier to integrate Python or Lua into the project and do it there. I don’t think integrating libuv into the stdlib would do much for anyone.
       
 (DIR) Post #9yefAgvVZaR9uNxLou by sir@cmpwn.com
       2020-08-30T17:25:34Z
       
       0 likes, 0 repeats
       
       I'm not proposing we do this, for the record. I just want to know how it would change things.
       
 (DIR) Post #9yeghdIOC4689pvjfM by foxcpp@puppo.space
       2020-08-30T17:43:46Z
       
       0 likes, 0 repeats
       
       @sir This would increase complexity of porting C toolchain to a new platform. On the other hand, this would enable many more software to be fully portable to any compliant platform. This would put the end to the endless chaos of dozens of different event-loop implementations all duplicating each other since there will be The One True implementation. (this is especially severe in C++ world that essentially builds on C)
       
 (DIR) Post #9yegtx9GCukdClXEVU by sir@cmpwn.com
       2020-08-30T17:46:43Z
       
       0 likes, 0 repeats
       
       @foxcpp porting wouldn't necessarily be more complicated than having select/poll or io_uring-alike syscallsIt would make implementing libc itself more complicatedAnd it would have no effect whatsoever on the toolchain
       
 (DIR) Post #9yerUNTIoYp2oNuu2q by mort@fosstodon.org
       2020-08-30T19:44:56Z
       
       0 likes, 0 repeats
       
       @sir Personally, I would just keep using poll probably, because the poll-based event loop model seems to work just fine. Especilaly in linux, where we have timerfd so poll can even be used to do things after a timeout.
       
 (DIR) Post #9yervDGOsNDmyEg5xI by sir@cmpwn.com
       2020-08-30T19:50:12Z
       
       0 likes, 0 repeats
       
       @mort poll is not directly related to event loops. Event loops typically use poll as part of their implementation.
       
 (DIR) Post #9yesS0po6iW5ylsZtY by mort@fosstodon.org
       2020-08-30T19:55:56Z
       
       0 likes, 0 repeats
       
       @sir I know. I'm saying that I would probably keep writing my event loops by manually call poll in a while loop and keeping track of file descriptors.
       
 (DIR) Post #9yeuKtfmXHXPeHvOu8 by nocko@makerdon.org
       2020-08-30T20:16:49Z
       
       0 likes, 0 repeats
       
       @sir Reinventing a 'good enough' abstraction over poll/epoll/select/timerfd is common... Having one with docs in the normal place, with known quality would be nice. I think in that way it could be better.I don't think it would change the way I use C, (e.g. adding additional use cases). It's always nice to dump a dep (usually libevent2 here).Maybe other impls would have incentive offer a similar API making it easier to swap in something specialized if there's a reason for it?
       
 (DIR) Post #9yf0YfZ2O7nffcik2i by foxcpp@puppo.space
       2020-08-30T21:26:51Z
       
       0 likes, 0 repeats
       
       @sir You are right. I (likely incorrectly) counted libc as part of toolchain.
       
 (DIR) Post #9ygHLqu4oIDfS8zml6 by Conan_Kudo@fosstodon.org
       2020-08-31T12:09:16Z
       
       0 likes, 0 repeats
       
       @sir I suspect it would make some improvement, since threading and concurrency would be more straightforward with C. You'd also be guaranteeing an event model that would exist across platforms, lending to greater source portability.