[swift-server-dev] Next Server Security API Group Meeting

Chris Bailey BAILEYC at uk.ibm.com
Tue Jan 31 08:10:48 CST 2017


Agreed - the ability to run non-blocking definitely a goal.

Chris




From:   Helge Heß via swift-server-dev <swift-server-dev at swift.org>
To:     swift-server-dev <swift-server-dev at swift.org>
Date:   30/01/2017 10:59
Subject:        Re: [swift-server-dev] Next Server Security API Group 
Meeting
Sent by:        swift-server-dev-bounces at swift.org



On 30 Jan 2017, at 10:59, Helge Heß <me at helgehess.eu> wrote:
> However, I thought - and I may be very wrong here, which would be 
excellent - that SecurityFramework only supported blocking read and write 
callbacks and cannot be ‘paused’ until new data arrives.

I’m just told off-list that this is not true. The lowest-level TLS API, 
Secure Transport, can be used in a non-blocking mode. Things like 
CFSocketStream and NSURLSession, actually use this facility to provide 
their async abstractions.

So I guess everything will be fine. Still the TLS API draft for Swift 
should state it as an explicit goal that it can be used in a non-blocking 
fashion.

Thanks,
  Helge

_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170131/601a5b1b/attachment.html>


More information about the swift-server-dev mailing list