[swift-server-dev] Thoughts on the current HTTP API
me at helgehess.eu
Mon Oct 16 11:00:55 CDT 2017
This mail can be kinda skipped and is only for those w/ spare time, it doesn’t add much to the discussion :-)
On Oct 16, 2017, at 5:41 PM, Johannes Weiß <johannesweiss at apple.com> wrote:
>> The important point is that the thing you need in the end is always a buffer, or better iovec. ‘Producing bytes on the fly’ is what you usually want to avoid as much as possible, IMO.
>> Instead you want direct and stable access to storage buffers backing the objects. (Which Swift unfortunately does not provide in the stdlib.)
> The main point is when writing Strings. There is no contiguously stored UTF-8 buffer but with "some string".utf8 we get an UTF8View which produces the bytes when needed.
Well, this is kinda incorrect. Correct is ‘there is not *always*’ a contiguously stored UTF-8 buffer. Quite often (a hell lot of time) there is (should be) one, but Swift hides the fact.
This is essentially my complaint :-)
>> Don’t know, I personally think it is overkill and I’m good w/ DispatchData. With the exception that I’d like to have API to get an iovec out of a DispatchData stack (instead of just the enumeration method we have now).
> yeah, a while ago I filed
> about it not being possible (in a guaranteed safe way) to use writev from [Data]/[[UInt8]]/DispatchData.
>> So what would
>> `func writeBody<Bytes: Collection>(_ data: Bytes, …)`
>> do? Presumably a malloc(), memcpy(from: data).
> well, that needs to happen somewhere. You can do it before passing it to the library or within.
Same like above. It needs to happen somewhere w/ the current Swift stdlib because you can’t get access to underlying buffers, which are usually already there and wouldn’t need to be copied.
>> (Especially if protocol calls imply a malloc, how crazy is that :palmface:)
> (only if the actual implementation's type is > 3 words (in Swift 4).)
I’m still a little flabbergasted that this was ever in, but sure, no need to complain about the past :-)
Now if they would fix the malloc when converting between cString and String …
>> But introducing explicit buffering for just that case, don’t know. Maybe. I guess +0.5.
> not saying we have to have it but I thought it might be worth bringing that up.
Sure, thanks, didn’t think of that.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 874 bytes
Desc: Message signed with OpenPGP
More information about the swift-server-dev