regi

38% + about 1 month of net income to pay each year as income tax. There's absolutely no visibility on retirement plan. You just know that you earn "points", with no idea what they're worth. Also, when you rent in France you have to pay a tax (similar to property tax) which, depending on the city, can be quite high (~1 month of rent/year). VAT is 22% on most products. Gas is expensive (highways too!!!). Train (TGV) is ridiculously expensive.

So I spent 3 years in Epitech, which forked into 42, and the first 4 weeks aren't a competition but more like an onboarding thing. You basically learn C in 4 weeks, with coding tests pretty much every day. It sets the base and it turns out to be a great way to quickly know if you really wanna be a software engineer. After these 4 weeks, students start working on group projects and regular CS classes (although teachers are senior students).

Oh, so this is your thing right? Checking people's background... https://news.ycombinator.com/item?id=8183055

;)

And as I'm saying in following comments, even in 2006, this was poor performance.

The C10k problem is 15-20 years old. Tcl uses select() which can handle a maximum of 1024 FDs. In other words, it would not be able to handle more than 1024 connections in parallel.

Moreover, Linux and FreeBSD have introduced syscalls comparable to select(): epoll (in 2002) and kqueue (in 2000). Those are way faster than select() and I think there's (virtually) no limit on FDs. Tcl must be using select() for its portability I guess.

So, handling a lot of concurrent connections is an old problem. In 2006, the C10k problem was way behind. Even at that time, I would have expected a program to be able to handle thousands of TPS.

"From SMTP filters/routers that handle millions of email deliveries a week to in-memory message journaling (for redundancy) that handle hundreds of transactions per second."

I stopped right there. To me, high performance is for instance, handling millions of emails per minute, thousands or tenth of thousand TPS. This is high performance, real life performance, not seen only in "physic labs and university research centers".

Some comments talk about Tcl using select. If this is true, it would mean a max of 1024 connections in parallel, kind of sad...

I fully agree. And besides being outdated, this article totally matches the expression: "Torture numbers and they'll confess to anything".

Wow. How many videos is this?!

It uses "user-space threads" similar to ucontext (swapcontext(3)). I have my own version: https://github.com/reginaldl/fcontext

Once the stack allocated for a thread, context switches are almost as cheap as a function call.

RiNOO has an event driven scheduler, based on epoll, which resume/release these user-space threads (that I call tasks) according to pending IOs. The library provides with IO functions (read, write...) which use the RiNOO scheduler.

As a bonus, real threading is quite easy: just need to run a scheduler per thread (see examples with multi-threading).

Callbacks can be avoided using co-routines. I started a project that uses asynchronous sockets but they appear synchronous. With a bit of abstraction, it's really easy to develop network applications even in C:

https://github.com/reginaldl/librinoo

And anything that requires more than 1024 fds...

How come this code has 117 stars on github?!

Here's something that is probably safer and that actually scales: https://github.com/reginaldl/librinoo

You show me yours, I show you mine ;) https://github.com/reginaldl/librinoo

Just to comment on your post, as using blocking calls in coroutine might be a nice feature I think it defeats the whole concept of coroutine. I might be missing the point but this kind of library is absolutely great for asynchronous network calls and in this specific case the library provides a whole set of functions like read/write/connect/accept etc...

I like the idea of being able to schedule coroutines on multiple threads though. In librinoo, I have the concept of 'scheduler'. A scheduler handles a set of coroutines and you can one scheduler per thread (that I called 'spawning').

Those libs are just awesome to quickly create scalable network programs. Well done.

We often forget that even though this common problem of replacing callbacks is getting more critical and urgent, people already thought about it and gave some solutions. Maybe not in higher level languages (although I think Go does a great job there). In C, I have in mind glibc's ucontext for example. I'm trying to improve that through rinoo. So to answer your question, if you look at the wiki section you'll see test results I've done running 20,000 Actors. Of course, once you handle "actors" correctly (which should definitely be called fiber) you shouldn't use that many Threads (if too many you'll end up spending most CPU cycles scheduling your threads). However, rinoo handles multi-threading as well. I'm currently writing doc about it.

Interesting. I'm attempting to do pretty much the same thing in C: http://github.com/reginaldl/librinoo