[swift-users] Autoreleasepool for Ubuntu

[Bernardo Breder]

In my http server i want to manager the memory all the time that we close a
socket, like the example of manager in this link:
http://stackoverflow.com/questions/25860942/is-it-necessary-to-use-autoreleasepool-in-a-swift-program

Algorithm that show the ideia:

*func request(content) { ... }*

*let server = myserver()*
*while let client = server.accept() {*
*  autoreleasepool {*
*    client.send(request(client.read()))*
*    client.close()*
*  }*
*}*

2016-11-02 18:08 GMT-02:00 Joe Groff <jgroff at apple.com>:

>
> On Nov 2, 2016, at 1:00 PM, Philippe Hausler <phausler at apple.com> wrote:
>
> See:
>
> https://github.com/apple/swift-corelibs-foundation/blob/
> d015466450b2675037c6f1ace8e17e73050ccfb9/Foundation/NSURL.swift#L561
>
> This is far and few between of cases that it would be useful but there are
> a few APIs that we have not been able to express without being able to
> autorelease items. Most of which we have either forbidden in Linux or
> redesigned because they were sub-par swift experiences. However it seems
> reasonable to have a minimal shim to provide cross platform code
> compatibility even if it does next to nothing. That way trivial code as the
> original issue showed can easily be directly compiled on either platform
> without littering gnarly #ifdefs about.
>
>
> In the fullness of time, the borrow model will hopefully give us a way to
> represent those kinds of "returns inner pointer" APIs safely in Swift
> without relying on dynamic lifetime extension, or awkward 'with { ... }'
> callbacks.
>
> -Joe
>



-- 
Nome : Bernardo Breder
Product : Breder Language
Site : bernardobreder.com
Email : bernardobreder at gmail.com
Email : bbreder at tecgraf.puc-rio.br
Email : contato at bernardobreder.com
Graduação : UFF - Ciência da Computação
Mestrado : UFF - Ciência da Computação
Trabalho : TecGraf - PUC-RIO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20161102/2ad4469e/attachment.html>