[swift-server-dev] Next HTTP API meeting

[Helge Heß]

On 29. Mar 2017, at 19:14, Johannes Weiß <johannesweiss at apple.com> wrote:
>> And we didn’t even discuss body streams yet, which I still find much more interesting due to the implications they can have on the I/O model :-) Paulo already mentioned the possible need for two APIs (async/sync), which matches my experience.
> 
> As per my email where I sketch what we use internally, we only have an async API. We have higher-level stuff on that and some does actually have sync APIs but why do you think we need both a sync and an async API? If someone wants a sync web framework, that's pretty simple to put on top of an async API.

I’ve been thinking a lot about that lately (since well, one of my projects Noze.io is async to the core while my other, mod_swift, is completely sync for practical purposes). I do not think that it is easy at all to put a sync API on top of an async one. But maybe you can enlighten me :-)

Yes, you can use a DispatchSemaphore to serialise the access and make GCD stuff work within sync environments, but as far as I can see this can’t be done in an automagic way right now. It would be cool if GCD would support that, something like a DispatchMain(), but more like WaitForEverythingScheduledFromThisThread().

The other thing is that async (not NIO) essentially requires @escaping closures while sync stuff often doesn’t. @escaping is a pretty big big overhead.

You can have the same user-facing API, like:

  readFile(“/etc/passwd”) { data in 
  }

but in a sync framework that would be

  func readFile(_ p: String, cb: (Data)->Void)

in an async framework it would be

  func readFile(_ p: String, cb: @escaping (Data)->Void)

Would be trivial with a #define in C, but due to the excellence of Swift, this is not that easy to do w/o copying large amounts of code ;-> (apart from always doing @escaping and live with copying the stack to the heap, adding ARC etc, which is plain lame).

Plus the error reporting issue (throws vs (error, result)).


>  So I'd argue we should only have an async API for the HTTP stuff this group proposes.

That sounds OK to *me*. If people want to do other stuff, they still can (libmill and such), it will just perform worse ...

hh