[swift-server-dev] Posix Module

[Johannes Weiß]

Hi Helge,

> [...]
>> So yes, just re-exporting Glibc/Darwin is easy but using these functions correctly is hard.
> 
> yes, all that is understood but it has absolutely no relevance to the namespace under which those "hard-to-use-functions" are exposed?
> 
> All I :-) ask for is that those Posix or C99 funds are exposed under a common name whether on Linux, Darwin, Windoze or BeOS.

Understood but that topic is already covered on swift-evolution. I'm more interested in making those functions usable correctly in Swift. Right now, "hard-to-use function" is an understatement IMHO, I have yet to see a guaranteed correct use of `errno` in any Swift open-source library but that should be discussed on swift-{evolution, users}.


>> Another assumption I have seen in Swift libraries is assuming that a successful system call resets errno to 0, that's not true either.
> 
> File a bug report against the respective libs. Of course this is not true and never has been true in C either.

Doing that. And, yes, that errno isn't guaranteed to be set to 0 on success has always been true in C. But capturing the correct value of errno is very straightforward in C and it's definitely not in Swift.


>> But as others have said, this might be a swift-{users,evolution} question?
> 
> It probably is, so are sockets, encryption and database access :-) I think you need to start somewhere, and Swift Server is the one place which has to deal with this specific issue right now.

Not sure if I fully agree. I see two areas here:

1) making the basic OS functionality available to Swift. IMHO that covers being able to call the OS's syscalls and being able to deal with the errors in a robust way. That for me belongs to swift-evolution but this work group could for example come up with proposals.

2) building libraries on top of these basic primitives. There's a bit more opinion involved here on how to do things. For example obvious questions about the programming model depending if based on Dispatch (DisptchIO or DispatchSource), one of the CSP libraries (eg. lib{dill, mill, venice}), blocking IO ;), or something else. But we should try to not bake too much opinion in these basic building blocks because that might make them incompatible with layers further up (like Zewo, Vapor, Kitura).

  Also we have to consider here that right now DispatchIO/DispatchSource is probably a reasonable place to start as Dispatch comes with Swift and a Swift API. But when (in maybe 1.5+ years) Swift gains a memory and concurrency model, Dispatch might not be the best way of doing things anymore.
 So I think it's too early to answer these questions in the Swift standard library right now. But in this work group we can start to discuss and implement(!) basic building blocks that help building server programs right now (or in the near future). These efforts would then make it a) easier to develop server software right now and b) reduce duplication in the existing server frameworks.

  Summing up, I think this workgroup could cover the layer above syscalls focussing on the areas that common server software needs (eg. networking, security, HTTP parsing, ...). Hopefully the layer can be as free as possible of decisions that massively influence the stack on top. It'd be great to see Vapor, Zewo and Kitura adopting these lower level primitives. And that should be possible without changing their overall architecture.

I hope that makes some sense. And for the record: The scope for the discussions/libraries that come out of this doesn't need to be massive. Personally, I'd be very happy if we'd produce some very few basic libraries that are used as a common ground to bootstrap network applications.

All the best,
  Johannes