How to build Apache modules in Swift | Hacker News Reader

How to build Apache modules in Swift

github.com

61 pointshelge524 comments

With regards to being able to call a Swift function from C, stevetrewick pointed me to @_cdecl early last year[0][1][2]:

    @_cdecl("foobar") public func foobar() {}

I haven't yet used it in anger, but that will compile in Swift 3.

[0]https://news.ycombinator.com/item?id=11650628

[1]https://github.com/apple/swift/commit/013aad13d4245a012cfb76...

[2]https://swiftlang.ng.bluemix.net/#/repl/d68be430e72609717f71...

Be careful; it currently relies on the Objecive-C runtime which is not present on non-Apple platforms.

As the PR says, it also doesn't handle turning throwing functions into errors, nor does it check for collisions.

Another thing you can do is declare a function pointer type in C and assign to it from Swift by calling a C setter function (more or less a small trampoline).

Exposing a c function from an objective-c file, and then calling into our swift code from there is what we've been doing since before this feature was enabled. That of course also requires the Objective C runtime, but we haven't changed to @_cdecl mainly because I'm more worried about the behavior changing than I am about anyone trying to run our swift code on Linux.

Assigning a block to a c function pointer is an interesting alternative, I thought we tried something like that but I can't remember now.

Hopefully @_cdecl will become a documented and supported feature.

Does @_cdecl mean "default C calling convention for the platform" or does it actually mean CDECL? How does that work on 64b systems?

My guess is the former since there aren't any 32 bit Apple platforms anymore.

I believe it is the calling convention. When I use it, if you look at the symbols/name mangling, what gets generated looks like a C symbol.

000061b4 T BlurrrSwiftEntry vs. 000061cc T _TF1MySDLMainActivity16BlurrrSwiftEntryFT_T_

Well, yes, but I'm unsure why you think that the calling convention has anything to do with the mangled name. That is just a name after all.

The name above is the name used to link the functions. The calling convention says how such functions end up being called and is directly represented by the machine code the compiler generates. For example, in which registers arguments are passed, or whether they are passed on the stack and in which order, etc.

The C `__cdecl` traditionally just specifies the calling convention, not the link name which is specified by `extern C`. Looks like the Swift `@_cdecl` combines the two.

I think in contrast the `@_silgen_name` just specified the link name and not the calling convention. (the result is exactly the same like your example). This is precisely the issue with using `@_silgen_name` - you have to be lucky that calling conventions happen to be the same for simple setups, like `(Void)->Void` or `(OpaquePointer!)->Void` - which seems to be the case at the moment.

https://msdn.microsoft.com/de-de/library/zkwh89ks(v=vs.80).a...

P.S.: I'm unsure why anyone would think that this has anything to do with the Objective-C runtime. I guess it may if you pass any kind of ARC objects.

"P.S.: I'm unsure why anyone would think that this has anything to do with the Objective-C runtime. I guess it may if you pass any kind of ARC objects."

Because the comment on the commit that adds this to the swift source states that "It relies on ObjC interop".

https://github.com/apple/swift/commit/013aad13d4245a012cfb76...

So maybe not the runtime, per se, but haven't looked into what it's actually generating.

>it currently relies on the Objecive-C runtime which is not present on non-Apple platforms.

Maybe I misunderstand you, but this doesn't seem to be the case, at least not in Swift 3.0-RELEASE. I was able to use @_cdecl for a callback in a Tcl extension (https://tcl.wiki/48057) on Linux.

I'm using @_cdecl on Android which doesn't have the the Obj-C runtime.

A nice, I might give that a try, though the

    @_silgen_name("foobar") func foobar()

does seem to work just fine for now. Could change in the future of course, though I wonder how likely it is that the calling convention for this kind of Swift function is actually going to change.

Note that the whole purpose of the function is to enter the Swift side from C just once. After that all is good, you can register any kind of convention-C callbacks.

What I'd like to see is the ability to specify `@convention(c)` not just on types, but also on functions and structs. That would be sweet and reduce the requirement for C wrappers even more.

I was either told or read (during the 2.x time frame) they were likely going to break @_silgen_name. @_cdecl was added to replace this (at least for my usage case), but I think it is still unfinished and not official, hence the leading underscore.

It happens that @_silgen_name didn't break for me in 3.0. But I've been moving to @_cdecl.

I switched to `@_cdecl` and everything still seems to work. Seems to be the much better option, thanks for the hint!

Pretty cool stuff. Too bad it's not available under an Open Source license. That kind of severely limits who can use it and what they can use it for. :-(

Maybe just ask if you want to actually use it for something (remember that it is explicitly marked as a tech-demo, not as something you should use). I've heard they are pretty forthcoming ... ;->

What do people still use Apache for? Hasn't everyone moved onto Nginx?

Not everyone follows fashion.

Apache2 is still better for servers that host lots of small applications (largely due to htaccess enabling "per directory" config). That's increasingly unusual as people move to nginx in containers, but it does still happen.

I know that YouTube runs (or previously ran) on lighttpd. Have there been any major developments/improvements as of late?

No. In fact Apache has more than double the share of Nginx (32% vs 14% of websites).

I have the impression (maybe mistaken) that the scriptable module story in apache is much more mature than with nginx. Apache has had mod_python, mod_php, mod_perl, mod_lua, etc for ages. If you're using nginx, then you're most likely proxying to a backend. I've used mod_lua and apache for an application server and infrastructure tasks to great effect. This is anecdotal of course.

Nginx is a pretty different thing. Its primary purpose is quickly delivering files on disk and acting as a proxy, specifically not executing custom code.

Apache is more like an application server framework specifically targeted at executing custom code (hence modules). It is a little obscure and old fashioned but actually quite powerful and very flexible/customizable.

Since many current server side frameworks (say Node.js and all other Swift frameworks I know) do not really embed well into the server but are HTTP servers on their own, Nginx is often used as a frontend server in such contexts. It is very good for that (and Apache often overkill).

Anyways, running your code within Apache has pros&cons, as always. But this has little to do with Nginx vs Apache. (i.e. it may still make sense to use Nginx in front of Apache hosting a mod_swift application).

People still use Apache for a lot of things... It performs just as well as nginx, and in some situations, like reverse proxy, is even better (more compliant). Talking about Apache httpd 2.4 of course... older versions weren't as good. Bad that's ancient history.

eww, mod_proxy. I've seen it do seriously weird things, and I have sysadmin friends who hate it with a vengeance.

Reply on news.ycombinator.com