Add post: Lifetime Event Loop

[straight-shoota]

This is a draft for announcing the event loop updates once crystal-lang/crystal#14996 is merged.

[netlify]

✅ Deploy Preview for crystal-website ready!

Name	Link
🔨 Latest commit	d5c8d6a
🔍 Latest deploy log	https://app.netlify.com/sites/crystal-website/deploys/673cb4b52182970008332c94
😎 Deploy Preview	https://deploy-preview-869--crystal-website.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[ysbaddaden]

Nice! I left a few suggestions, plus:

• maybe change the title to "A new Event Loop for UNIX operating systems", so we don't give the impression that we completely overhauled the evloop;
• maybe add a note about io_uring (not forgotten, we have plans).

Last but not least: the flag is currently -Devloop not -Deventloop. I don't have strong feelings about either, but we need to settle on one.

[crysbot]

This pull request has been mentioned on Crystal Forum. There might be relevant details there:

https://forum.crystal-lang.org/t/new-event-loop-unix-call-for-reviews-tests/7207/22

[beta-ziliani]

As with the RFC, the breaking change should be shouted out. Also, the distinction between transferring FDs without pending operations should stand. More like "It is possible to transfer a file descriptor between threads as long as there are no pending operations."

[beta-ziliani]

This last bit is to not make it sound like trasferring is not possible at all (for the casual reader)

[beta-ziliani]

@straight-shoota have you seen this?

[zw963]

Cool, if we removes the libevent as a runtime dependency, does it mean we can statically compile a binary on Linux use GNU toolchain now?

[zw963]

Last but not least: the flag is currently -Devloop not -Deventloop

I consider latter is better?

[straight-shoota]

Cool, if we removes the libevent as a runtime dependency, does it mean we can statically compile a binary on Linux use GNU toolchain now?

No, this doesn't affect that. The trouble with static linking is with the GNU libc itself. Linking libevent statically is no issue.

[zw963]

Yes, it not work.

 ╰──➤ $ 1  crystal build --static 1.cr
/usr/sbin/ld: cannot find -lgc (this usually means you need to install the development package for libgc): No such file or directory
/usr/sbin/ld: cannot find -levent (this usually means you need to install the development package for libevent): No such file or directory
collect2: error: ld returned 1 exit status
Error: execution of command failed with exit status 1: cc "${@}" -o /home/zw963/Crystal/crystal-china/procodile_cr/1  -rdynamic -static -L/home/zw963/Crystal/bin/../lib/crystal -lgc -lpthread -ldl -lpthread -levent -lrt -lpthread -ldl

But, Why it still depends on libevent?

 ╰──➤ $ 1  cr version
Crystal 1.15.0-dev [6cec6a904] (2024-11-15)

LLVM: 18.1.8
Default target: x86_64-pc-linux-gnu

[straight-shoota]

But, Why it still depends on libevent?

The PR mentioned in this draft post has not been merged yet, so the change is not yet available in master/nightly.
It'll be when the post is published. Until then you need to use the PR branch.

[beta-ziliani]

I would also move the section about MT before timers. The program changing behavior is more important than a not that much noticeable performance regression.