[swift-server-dev] Posix Module

Helge Heß me at helgehess.eu
Sun Oct 30 04:24:44 CDT 2016


On 30 Oct 2016, at 07:29, Tyler Cloutier via swift-server-dev <swift-server-dev at swift.org> wrote:
> I think this goes beyond just that proposal, though. It’s not just a problem of conditionally importing both frameworks as there is sometimes a slight mismatch in the API. This results in me having to do unfortunate things like this:
> 
> https://github.com/SwiftOnEdge/Edge/blob/8bdbb4555dd49ecfad51498234f4d91cdf07d4aa/Sources/POSIXExtensions/Socket.swift#L18

I wouldn’t go that far, I mean this is just a struct. There is nothing wrong with not using the convenience initialiser and doing a `var address = addr()` and then initialising the values. No portability issue here (BTW this worked fine before, SE-0060 b0rked it, maybe we are getting the old struct-convenience-initializer behaviour back later, I’m kinda counting on it :-).

On a higher level you wouldn’t want to access the ai_* values directly anyways (but rather something which gives you a string value, etc). But I wouldn’t even put those wrappers I have in my `xsys` module into that Swift `Posix` module. This one should be just the Posix API exposed, same like in C. The latter may be more like an extra `SwiftyPosix` module.


Is anyone else interested in having a module which enhances the Posix/CLib structs to be swiftyer? I think I currently have some code for socket addresses, the mentioned addr and for time value stuff (time_t, timespec, timeval).


> A standard POSIX Swift API would reduce some serious pain points in developing for the server. All of this translational work from C APIs to Swift APIs is happening in every project that does low level I/O. Ideally it would be as thin a wrapper as is possible while still making the APIs feel Swift-y.

I wouldn’t even make it a wrapper. Just expose the Posix/C-stdlib subsystems under a common name. We could still do `#if linux` for cases where it is really necessary. (it shouldn’t be for the regular Posix socket demo doing a connect(), send(), recv() and close() …).

The platform which is a bit special wrt Posix is Windows. That may indeed require some renaming (all the socket stuff being prefixed with WSA etc). Though a higher level socket lib may want to do Windows differently anyways, not sure.


> Can you imagine not having to mess about with errno anymore? I dream of the day.

Well, yes. But that should really live at a higher level. I was just talking about the

  #if os(Linux)
    import Glibc
    public let connect = Glibc.connect
  #else
    import Darwin
    public let connect = Darwin.connect
  #endif

… which is just ridiculous :-)


My understanding is that there likely wouldn’t be a big resistance towards having a common Posix/CLib module. There ‘just’ needs to be someone implementing a pull request for the Swift codebase (aka do the work).
That’s not me, easier for me to just do the funky mappings :-)

hh

P.S.: I think the discussion kinda belongs here because server-side is the main use case for X-platform stuff until the Android port begins to fly ;->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161030/040db6ea/attachment.sig>


More information about the swift-server-dev mailing list