Kore: a fast web server for writing web apps in C

by api • 11 years ago

271 165 11 years ago

ejcx2• 11 years ago

This looks pretty neat actually. A ton of effort clearly went into it and it looks like the code is really well written with pretty well thought out interfaces

"Its main goals are security.."

Is it actually?

I also don't really see an advantage of using something like this over something like the Go net/http package.

Web-type API stuff is usually high enough level that something like C doesn't make sense. Go has nice enough standard packages for system things that even if I was doing a lot of system-y stuff I would be alright. I don't really see the type of work I would be doing where I want to use this.

mambodog• 11 years ago

It does seem like if your goal was security than perhaps Rust would be a better choice.

ZoFreX2• 11 years ago

If your goal is security literally any high level language is a better choice.

vidarh4• 11 years ago

Rust won't help you on the dozens of platforms it isn't available.

jzelinskie• 11 years ago

I can see this being useful for embedded systems where Go is not suitable. I'm not super familiar with that whole world, though.

ejcx2• 11 years ago

Ahh that is a use case I hadn't considered. I guess it would be pretty useful if some type of basic webserver was required.

jvink13• 11 years ago

It is.

For example being strict on the network input path and doing proper validation of incoming data is a strong part of the design.

Or was the question more related to, it is C therefor security cannot be part of the process?

vidarh4• 11 years ago

I also don't really see an advantage of using something like this over something like the Go net/http package.

C runs "everywhere". Your old C64 from the 80's? Has C compilers.

Go does not, even with gccgo.

I'd bet there are also still likely at least two orders of magnitude more programmers that know C well, and still more programmers with in depth experience of embedded development in C than have even tried Go.

I've still yet to meet anyone outside of the startup devops bubble that have written any Go, and often what language the developers have experience with matters more.

pjmlp11• 11 years ago

Your old C64 from the 80's? Has C compilers

Yeah, but the idea to use them back then was like trying to use Ruby for real time applications in modern days, given how shitty they were.

Home computers might have had implementations of C and Pascal dialects, but we all used Assembly when stepping out of the built-in Basic and Forth enviroments.

danieltillett4• 11 years ago

Has anyone done any performance testing on kore? Yes I know I can do this myself, but why invent the wheel.

delinka• 11 years ago

You'd invent the wheel to get you places. You wouldn't reinvent the wheel when someone's already done a perfectly good job.

danieltillett4• 11 years ago

So much for me trying to be clever and avoid a cliche :)

rch3• 11 years ago

as in... http://okws.org

yuvipanda• 11 years ago

Awesome! I've used https://www.gnu.org/software/libmicrohttpd/ in the past (for fun stuff I was building to learn C), will try this out instead. But..

Only HTTPS connections allowed

Seems a bit painful. HTTPS on the webserver itself is a fair bit more painful to setup and administer than HTTPS in your reverse proxy / loadbalancer (I prefer nginx). Web servers should support plain HTTP.

bubblesorting• 11 years ago

I'm not trying to antagonize here, but what do you find so bad? I would call it a little bit more painful; three lines to add to an nginx config, along with generating the cert. Maybe 10 minutes of work? Thirty if you're getting a CA to sign your cert for you. I could see pain if you need to wait for finance to approve, or if you're trying to get domains validated on behalf of a customer. And I suppose it adds another setup step to wireshark (if you need to debug neat bugs), but that's a set-it-up-once-and-forget-about-it thing.

Canada3• 11 years ago

It's a scalability problem.

If you have many web servers behind a reverse proxy that takes care of TLS it's often pointless to waste processing power on encryption in between.

jvink13• 11 years ago

You can turn off TLS on Kore.

$ make BENCHMARK=1

It is not a run time option by design, but it is there.

I want Kore to have sane defaults for getting up and running. That means TLS (1.2 default by only), no RSA based key exchanges, AEAD ciphers preferred and the likes.

edit: spelling

crest• 11 years ago

RSA with DHE or ECDHE is a sane handshake. I would avoid DSA and ECDSA based key exchanges because they fail catastrophically with bad random number generators. For most APIs session caching is more important than a faster initial handshake.

The HTTPS only choice would annoy me a lot because I run most HTTPS services in behind a reverse proxy in a FreeBSD jail on the same host. HA proxy and nginx are still superior to most applications in regard to reliable TLS termination.

Using HTTPS by default a the right choice for a new project but offering no HTTP support (outside of a benchmark) patronizes the user.

All in all this looks like a nice way to export C APIs through HTTPS.

mitchi• 11 years ago

Everytime something like this comes out, I think the following : Wouldn't it be great if I could develop and debug this under Windows with VS and deploy my release with Linux. The network libraries are always Linux(and family) only.

provost• 11 years ago

I don't see a reason why you can't make it cross-platform, with a bit of effort: https://github.com/jorisvink/kore

rdtsc4• 11 years ago

The site and documentations looks well done, great job!

Architecture looks pretty interesting too. Wonder why was there a need for an accept lock? Ordinary accept() socket call already allows for simultaneous threads/process wait on a single socket.

luikore3• 11 years ago

I think the authors want to avoid thundering herd. You can find this basic pattern in the book UNIX Network Programming.

rdtsc4• 11 years ago

Hmm, thought that was fixed 10 years ago or so. I can't believe the standard accept() call will wake up all threads on a modern Linux kernel.

Maybe if it is using epoll/select/etc. it would exhibit the thundering herd issue.

jvink13• 11 years ago

Correct.

The accepting socket is shared between multiple workers which each have its own fd for epoll or kqueue. Because of this a form of serialising the accepts between said workers is needed to avoid unnecessary wakeups.

slowmovintarget• 11 years ago

Writing a web application in C sounds like a good trigger for an utterance from the Jargon File: "You could do that, but that'd be like kicking dead whales down the beach."

We've advanced the state of the art quite a bit with dramatically more expressive languages than C that are sufficiently efficient in terms of memory and CPU. This is especially true when communications are occurring over HTTP and not direct socket-to-socket comms.

Why use C instead of D, Rust, Go, C#, Java, Perl, Python, Ruby, Scala, Clojure, Erlang, Elixir, Haskell, Swift, OCaml, Objective-C...?

I didn't miss C++, it just seems a worse alternative than C.

nulltype2• 11 years ago

Thank god it's written in C and not C++

CountSessine4• 11 years ago

Yeah. Thank God. I love broken string implementationsssssdd##%^$*$#@@#$%$$$###ludvik^0knox^0shamen^0password^0pass^012345^0qwerty^0dreamdevil^0

C is just awesome.

perdunov2• 11 years ago

I didn't miss C++, it just seems a worse alternative than C.

This is such a retarded opinion. A person expressing it probably doesn't know shit about C++ or just plainly an idiot.

vidarh4• 11 years ago

Why use C instead of D, Rust, Go, C#, Java, Perl, Python, Ruby, Scala, Clojure, Erlang, Elixir, Haskell, Swift, OCaml, Objective-C...?

Because C runs pretty much anywhere? There are plenty of platforms where C is available where I doubt you'd find any of the others above (e.g. C64; yes there are C compilers for them; yes, I'm mentioning it tongue in cheek)

Because you can generate small, compact static executables? E.g. I used to write network monitoring software and an accompanying SNMP server for a system with 4MB RAM and 4MB flash, the latter of which had to include the Linux kernel and a shell on top of the application in question. The system was so limited we did not run a normal init, and couldn't fit bash - instead we ended up running ash as the init...

There are plenty of use-cases where "web application" == "user interface for a tiny embedded platform".

snarfy• 11 years ago

Because C runs pretty much anywhere?

I always hear this argument, but as time has progressed, for better or worse 'anywhere' has become a much smaller target. If your language runs on Intel and ARM then it's good enough. There are a lot of reasons I might choose C for a project, but 'run anywhere' is not one of them.

xamuel• 11 years ago

C is a good solution for things like realtime multiplayer with lots of state, lots of side effects, etc. A lot of the modern abstractions actually get in the way, for example:

* List traversal order matters a lot when it's something like a list of monsters getting struck by a spell and the spell has complicated side effects. Brushing it under the rug with abstract iterators or functional Array.map's is a recipe for not knowing how your own game works.

* Realtime is an illusion, it really means "fast turn-based", you don't want players with fast connections to get an advantage by spamming commands and having them executed the instant they're received. You want to queue commands and execute them fairly at regular pulses. So much for all your abstract events infrastructure!!

* Certain object-oriented idioms become eye-rollingly silly when your application actually involves _objects_ (in the in-game sense). Suppose it's a game where players build in-game factories, suddenly the old "FactoryFactory" joke just got a million times worse.

I'm not saying C is the best for those sorts of applications, but it's certainly not bad, and a lot of modern language features just aren't appropriate.

csomar• 11 years ago

Why use C instead of D, Rust, Go, C#, Java, Perl, Python, Ruby, Scala, Clojure, Erlang, Elixir, Haskell, Swift, OCaml, Objective-C...?

C and Rust are not in the same play field of Ruby, Python or PHP. These languages are typed, compiled and MUCH faster.

You'll obviously build 99% of your application in Ruby, but you might need C or Rust for high-volume calculations.

An example that happened to me a few weeks ago. Scaling a financial application to make millions of calculations. The core App is made with PHP, and the difference between 0.1sec and 0.000764sec gets important here.

dang• 11 years ago

Previously: https://news.ycombinator.com/item?id=5995298.

windlep• 11 years ago

Was quite excited to try out a little websocket server with Kore till I saw it fork's per connection. I don't really want 20k processes for handling 20k connections, I was really hoping for an event loop.

altano2• 11 years ago

Evented io is great for extremely high concurrency, but that isn't always the right thing to optimize for. A forking web server might be faster for users depending on the application.

Lastly, you can't just have an event loop without also creating an entirely async platform. For an event loop to work well, all operations from file reading to network requests need to be completely async.

bazookajoes• 11 years ago

Out of curiosity in what scenarios do you see a forking web server being faster than a evented server that balances requests across cores and can direct a request to the core with the best cache for the request?

I completely agree with need to async. The hard part is that many operations are async without an async interface. For example memory allocation, or even memory usage if the memory was not truly allocated by malloc.

giancarlostoro• 11 years ago

There's always Vibe.d from the D programming language. Granted you would have to write in D, but most of the libraries of C are available. Concurrency is definitely accounted for since D supports it internally in the language. If you're seriously considering a 'native' approach to web development.

luikore3• 11 years ago

Really?

| Event driven architecture with per CPU core worker processes

So each process should be able to handle a lot of concurrent connections, just like nginx.

And I tried the websocket example, and saw only the first worker process responding whenever a websocket is created.

alexchamberlain• 11 years ago

Unless you are optimising for space, there is no real reason to use C in IO bound processes (for which event loops are ideal); you may as well use Python (or even JS if you must) as your performance will be dominated by IO time.

jvink13• 11 years ago

Kore does not fork per connection.

It uses an event driven architecture with per CPU worker processes. The number of workers you have can be controlled by the config.

rezacks• 11 years ago

I've used https://github.com/cesanta/mongoose in the past maybe I could try this one.

randomfool• 11 years ago

I'm curious- why C? Strings, scoped objects and C++11 move operators seems much safer and clearer from an API perspective.

The complaints about C++ seem to mostly be around the ability to abuse the language, not specific issues that C solves. Something like https://github.com/facebook/proxygen seems like a better API.

And I don't quite buy portability- if it's not a modern compiler with decent security checks then I'm note sure it should be building web-facing code.

luikore3• 11 years ago

Why not? I'd love to build web applications on a router with pure C.

tomcam• 11 years ago

Man, me too. I feel more comfortable knowing where all my memory is, and that my types are being checked at compile time.

gizi• 11 years ago

C++ is just one of the many failed attempts to improve on C. So, yes, C has its issues, but C++ is certainly not the solution.

The long story. There are three dominant Turing-complete axiomatizations: numbers (Dedekind-Peano), sets (Zermelo-Fraenkel) and functions (Church). The Curry-Howard correspondence shows that all Turing-complete axiomatizations are mirrors of each other.

If "everything is an object", it means that there must exist a Turing-complete axiomatization based on objects.

Well, such axiomatization does not exist at all. Nobody has phrased one. Therefore, object orientation and languages like C++ are snake oil. They fail after simple mathematical scrutiny. C++ is simply a false belief primarily inspired by ignorance.

bch• 11 years ago

C is ripe for integrating with other higher level languages, and the no-fuss license encourages this. I'm looking forward to checking this out further. Good luck Kore!!

byuu• 11 years ago

I've been building an HTTP/1.1 server in C++11. Along with a C++ wrapper around SQLite, I've been having a lot of fun putting some lightweight forum software together. I definitely enjoy the code structure and compile-time safety over PHP.

Using a threaded model with tiny stacks, and std::lock_guard for atomic operations.

The biggest downside is you have to run the same OS your server uses on your dev box (which is what I do); or you have to upload the source and compile the binaries on your server directly. (or have fun with cross-compilation, I guess.)

To answer the inevitable "why?" -- for fun and learning. Kind of cool to have a fully LAMPless website+forum in 50KB of code. Not planning to displace nginx and vBulletin at a Fortune 500 company or anything.

Still wishing I could do HTTPS without requiring a complex third-party library.

imron3• 11 years ago

The biggest downside is you have to run the same OS your server uses on your dev box

You should check out Docker.

Canada3• 11 years ago

I find this so much more pleasant to use than the alternatives. There's a portable distribution of it which you can put in your project and statically link.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/...

mborch• 11 years ago

Just put HAProxy in front of your server. You'll want that anyway most likely.

giovannibajo1• 11 years ago

Go would solve the problems you mentioned (cross compilation and HTTPS support), and would also offer first-level support to many web concepts and protocols that you need to implement from scratch in C++ as the ecosystem is not there. Of course if it's just for fun, then anything goes :)

pjmlp11• 11 years ago

The only valid reason is for those embedded devices where C and Assembly are the only languages being supported by the vendors SDK.

But I doubt such tiny processors are being used in boards with network capabilities.

perdunov2• 11 years ago

It seems that people are so intimidated by the infamous complexity of C++ that they don't even want to bother getting more familiar with it.

So, although technically the existence of C doesn't make sense, as it is superseded by C++ (except couple of things), C is winning in the branding department.

pron2• 11 years ago

I don't know if this is the reason why people choose C over C++ for some projects, but if language complexity is the reason, it isn't that people are just "so intimidated by the infamous complexity of C++ that they don't even want to bother getting more familiar with it".

In the 90s, C++ was much more popular than it is now. It was used as the go-to general purpose language for all kinds of "serious" software (not addressed by VB or Delphi). Early on, almost everyone was very impressed with the power C++ brought, but after a few years, as codebases aged, it became immediately clear that maintaining C++ codebases is a nightmare. The software industry lost a lot of money, developers cried for a simpler, less clever language, and C++ (at least on the server side) was abandoned en-masse -- almost overnight -- in favor of Java, and on the desktop when MS started pushing .NET and C#. So while today C++ is servicing its smallish niche quite well, as a general-purpose programming language for the masses it actually proved to be an unmitigated disaster. It is most certainly not the case that C++'s infamous complexity is "intimidating"; C++'s complexity is infamous because of the heavy toll it took on the software industry. Which is why, to this day, a whole generation of developers tries to avoid another "C++ disaster", and you see debates on whether or not complex, clever languages like Scala are "the new C++" (meant as a pejorative) or not.

Mikhail_Edoshin• 11 years ago

I can learn complex stuff, but with C++ I don't C the point :) Honestly, I don't see what I'd buy with all that complexity.

weland• 11 years ago

I am (or at least used to be, at some point) fluent in C++ and have built large applications with it. But I'd still rather write C, because its infamous simplicity is of a lot of use to me -- whereas I found that much of C++'s complexity tends to solve a lot of problems UML designers think we have, and very few problems that we actually have.

Nursie2• 11 years ago

The exietence of C makes perfect sense thanks, it's a relatively small and simple language with masses of flexibility.

C++ adds masses of complexity and implicit behaviour. While development in C++ can be quicker and might be 'safer' it can also produce all sorts of unexpected problems.

It also encourages all sorts of nested template types that can make existing codebases incredibly hard to read.

Further, in embedded situations, you may not have space for its standard library.

Dewie32• 11 years ago

So, although technically the existence of C doesn't make sense, as it is superseded by C++ (except couple of things), C is winning in the branding department.

Programming Languages are in the domain of UX. Type systems, syntax, RAII -- they all just a serve a means to an end, which is useability.

yoklov• 11 years ago

Not really. I'm sure this happens some of the time, but I suspect that's more common with developers who haven't written either.

In my experience, a lot of the developers who prefer C to C++ are developers who wrote a lot of C++, found that it only improved productivity in solving problems that it created, and went back to C and realized how much easier it is to write software in C.

C++ gets you caught up thinking about problems that don't even matter.

bjourne• 11 years ago

Embedded systems. For example a surveillance camera could have a small web interface for configuring it and allowing remote access. Nowadays, even cameras have enough power to run real web servers with Ruby on Rails, but for smaller embedded systems, like a pacemaker, a web app written in C could make sense.

SamReidHughes• 11 years ago

My impression has mostly been that on weird embedded platforms you'll just have some bad C compiler available, and that's the reason. Is it more than that?

rwmj• 11 years ago

Actually C with a pool allocator is an excellent language for writing a web server. I wrote one in C 15 years ago, and the code is very elegant and simple:

http://git.annexia.org/?p=rws.git;a=tree

swalsh• 11 years ago

I don't know if this is very heavy, so i might be wrong here. But one thing I can think of is embedded applications that want to have a web UI?

techar2• 11 years ago

C++ is really horrible, everything feels like an after thought. The new unique_ptr and shared_ptr ends up with really ugly code, the concept is good but wow...

Can we move away from this horrible language already?

http://harmful.cat-v.org/software/c++/ http://harmful.cat-v.org/software/c++/coders-at-work http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/rms

ludamad• 11 years ago

C++ is a swiss army knife that works with C, which I have learned very well and have great tools for. I understand the concern, but moving away is not so simple. That being said, I prefer well-designed C-style libraries in a lot of cases, since C++ libraries often have opinionated styles (the language is huge, after all).

pmelendez5• 11 years ago

I don't know about your case, but most of the time I found complains like yours , is from people who never actually tried the language, or just heard a bad story or have one bad experience reading a bad legacy code.

I think Torvalds and Stallman fall in that category actually. Stallman even mention generics which C++ doesn't have and it is very different to the templates mechanism that C++ does have.

As for the people who actually uses the language (specially after C++11), most of them would tell you that there is a great subset of the language that works for them. A valid argument I have heard before is that subset is different with each people and the problem arises when maintaining somebody else code. Well that happens with every language (Have you ever had to debug a memory corruption bug in an old C code with void* all over the place? Hint: it's not pleasent )

C++ is a language that allow you to use abstractions with a very reasonable performance and very reasonable resources, and in that niche there is not a real alternative.

Yes, you can have a fine tuned VM running Java or .Net code that might be comparable with C++ but with a cost in memory. I don't think Rust or D are ready yet to be a real competitor.

So... no... we can't move away from this "horrible" language yet.

api2• 11 years ago

I use it a lot, and find it to be quite tolerable once you get it. Its verbosity is a wart, but it's understandable when you understand what it is. ObjC has [[similar syntactical] issues].

The trick to it is not to over-use or abuse the language's many features. I tend to write C++ that is a fairly thin layer on top of C, using the STL for data structures and algorithms but using things like my own templates very sparingly.

I like Go, but it's really only well supported server side. Rust is promising but not ready for prime time.

tim_sw• 11 years ago

Isn't nginx written in C?

poindontcare• 11 years ago

hmm maybe put it in the kernel and use it for debugging? cant use userspace threading libraries though.

golergka2• 11 years ago

So, on one hand, it's one process per connection and ease of development of C, but on the other hand, it has execution speed of C.

Can anyone who works in web (I don't, but I'm curious) explain what kind of services is this good and bad for?

tomjen3• 11 years ago

Control interfaces to embedded devices?

golergka2• 11 years ago

Thanks, that actually seems to be the perfect use-case (from my almost non-existent experience with web development).

jvink13• 11 years ago

It is not a forking web server.

It is evented I/O with multiple worker processes.

It is literally in the documentation and easily spottable in the code.

vbernat• 11 years ago

When an HTTP API is just an additional feature of a larger project, it may make sense to keep using C: a toolchain available everywhere and well known (including cross-compilation and full bootstrap), a small memory footprint, easy use of any library needed for the project.

I am doing a lot of that and will keep a look at Kore. Unfortunately, HTTPS only and non-evented core is a no-go for me.

I am currently relying on the web server embedded in libevent, as well as wslay for websockets and some additional code for SSE. To easily start a project, I am using a cookiecutter template: https://github.com/vincentbernat/bootstrap.c-web

jvink13• 11 years ago

Perhaps you can check out the websocket and SSE examples.

https://github.com/jorisvink/kore/tree/master/examples/sse https://github.com/jorisvink/kore/tree/master/examples/webso...

unixprogrammer• 11 years ago

It speaks poorly of this community that you get second-guessed more for building an application in C than for building one in JavaScript + Node.js.

j-pb2• 11 years ago

If you want to use C today you need a really good excuse. The tradeoff between security and performance is simply not there anymore.

Unless you write on an embedded system, a game, or a high performance number crunching application, C is premature optimisation.

And even in the above we see drastic changes today, embedded systems have become so powerful that they can run scripting languages (http://www.eluaproject.net), game engines are written in C and scripted with other things (http://docs.unity3d.com/ScriptReference/), and inmemory-bigdata systems like spark offer significant advantages over classical HPC frameworks like MPI (http://www.dursi.ca/hpc-is-dying-and-mpi-is-killing-it/).

While JS is horrid, it at least doesn't have manual memory management.

fla2• 11 years ago

C is alot about portability, not necessarly performance.

Dewie32• 11 years ago

You're right, unixprogrammer; real hackers write everything in the venerable C.

On the other hand, there is a fair bit of negativity in this thread, just because it is C. That might not be in the hacker spirit, so to speak.

stefantalpalaru• 11 years ago

You can also do that with uWSGI: http://uwsgi.readthedocs.org/en/latest/Symcall.html

zippie2• 11 years ago

Process per connection does not scale no matter how light weight, even with COW. kore's connection handling model is the reason apache2 mpm_prefork fell out of favor many iterations ago.

The only valid argument to avoid a single event based I/O is some sort of hard blocking I/O such as disk or non-queuing chardev.

However I'm still not biting, this is solved...and as usual the answer is somewhere in between. For example, in RIBS2 there are two models for connection handling, event loops for connections and "ribbons" for the non-queuing bits [1]. RIBS2 is also written in C for C.

[1] https://github.com/Adaptv/ribs2/blob/master/README

Edit - mention RIBS2 is also written in C

jvink13• 11 years ago

Kore does not fork per connection.

It uses per cpu worker processes which multiplex I/O over either epoll or kqueue.

zippie2• 11 years ago

A clone is a clone. The main inplementation difference between a thread and process in Linux is COW, for all intensive purposes a worker process and a fork are the same in this use case. Neither have led to scalable web servers.

otterley2• 11 years ago

apache2 mpm_prefork fell out of favor many iterations ago.

By whom, exactly? There are still plenty of reasons to use a forking web server (see my other comment in this discussion). Saying it "does not scale" is misleading; even with a event-driven model there are only so many CPU resources that can be used to serve responses to clients.

Event-driven webservers are fantastic compared to forking ones, for keeping open many thousands of relatively idle connections (if that is your definition of "scale"). But many web services simply don't do that.

Preforking webservers, like event-driven ones, still have a rightful place in this world. As with all things technology, you have to pick the right tool for the job.

faragon4• 11 years ago

Writing high level C applications can be easy, if you use a library that frees you from using dynamic memory on typical data structures (e.g. strings, vectors, sorted binary trees, maps). I'm developing a C library for high-level C code, with hard real-time in mind, is already functional for static linking: https://github.com/faragon/libsrt

maciej• 11 years ago

If you think Kore is interesting, then also check out Tntnet <http://www.tntnet.org>. I've checked it out a few years ago and it felt good - stable, complete, easy to use etc.

bitL• 11 years ago

Good job & good luck! ;-)

sownkunz• 11 years ago

this is AWESOME!

talnet• 11 years ago

Anyway I love this.

z3t4• 11 years ago

Kore mapped to JavaScript (NodeJS):

  var kore = require("kore");

  kore.on("request", http_request);

  function http_request(req, resp) {
    var statusCode = 200;
    resp.write("Hello world", statusCode);
  }

bubbba• 11 years ago

Probably it would be better to have also a lib or dll, not just a program that render c/c++ servlets. It seems that all (that the kore executes from the feeded code) is running in servlet threads or at least started from servlet thread. Or it would be cool to add some "application" framework, not only "C-servlet" framework

unwind2• 11 years ago

Great! This looks really nice, and interesting.

Some fantastically quick points from a very cursory glance at the code. Feel free to ignore this.

- The code uses the convention to put the argument of return inside parentheses, making it look like a function call. This is very strange, to me.

- It treats sizeof as a function too (i.e. always parentheses the argument).

- It is not C99, which always seems so fantastically defensive these days.

- It's not (in my opinion) sufficiently const-happy.

- I saw at least one instance (in cli.c) of a long string not being written as a auto-concatenated literal but instead leading to multiple fprintf() calls. Very obviously not in a performance-critical place, so perhaps it's not indicative of anything. It just made me take notice.

jvink13• 11 years ago

Author here.

I see you picked out the few things that I consistently hear on the coding style I adopted which is based on my time hacking on openbsd. I have no real points to argue against those as it is based on preference in my opinion.

I am curious why you arrived on it not being sufficiently constified however. I'll gladly make sensible changes.

As for the multiple fprintf() calls ... to me it just reads better and the place it occurs in is as you stated pretty obvious non performance critical.

unwind2• 11 years ago

Right. I could have guessed these were based on some coding style guide from somewhere.

I still don't see the point, or why any sane guide would prefer to treat return as a function. It just never seems helpful to me, and always wasteful/more complicated. I realize it's just two tokens, so it's probably not "important" in any real sense of the word, but it irks me. I like to point it out since it can help others cargo-culting this.

It's not sufficiently const if there are places where a variable could be const but still isn't. :) To be super-specific, the variable 'r' here: https://github.com/jorisvink/kore/blob/master/src/cli.c#L542 is one such case. It should be declared inside the loop, i.e. as "const ssize_t r = write(...);" since once assigned the return value from write(), it's read-only.

Of course, many ancient-smelling style guides seem to outlaw declaring variables as close to their point of usage, too. Note that declaring variables inside scopes other than the "root" one in a function isn't even C99, but many people seem to think you can't do that.

Kore: a fast web server for writing web apps in C

Related Stories