<div dir="ltr">All,<div><br></div><div>Thanks for all your help thus far. I'll have some time this weekend to try things out but wanted to let you know that I'm only using Linux-native tools: vim, swift binary from the command line.</div><div><br></div><div>To this end: meaningful error messages, friendly API documentation, comparability to Python / Node / Ruby for interacting with the web etc. are all the things I'm investigating. Apparently a task that's come up is friendliness around coding around the asynchrony model ;)</div><div><br></div><div>Thanks for the suggestions, I'll work through them soon and report back.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 27, 2016 at 6:32 PM, Dave Abrahams via swift-users <span dir="ltr"><<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Pasting a reply on behalf of Matt Wright (cc'd):<br>
<br>
> On Oct 27, 2016, at 1:57 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>> wrote:<br>
><br>
><br>
> From: Steven Harms via swift-users <<a href="mailto:swift-users@swift.org">swift-users@swift.org</a>><br>
> Subject: [Swift3][Linux][URLSession]: Core dump when trying to make simple HTTP request<br>
...<schnipp 40>...<br>
> Date: October 27, 2016 at 5:01:58 AM PDT<br>
> To: <a href="mailto:swift-users@swift.org">swift-users@swift.org</a><br>
> Reply-To: Steven Harms <<a href="mailto:sgharms@stevengharms.com">sgharms@stevengharms.com</a>><br>
<div><div class="h5">><br>
><br>
> Hello Swift,<br>
><br>
> I've been trying out Swift as a general utility language on the server (replacing Ruby or Node). I'm trying to write a simple image retriever via HTTP as a learning project.<br>
><br>
> Inspired by this [gist][], I've written the following:<br>
><br>
> let queue = DispatchQueue.global(qos: .background)<br>
><br>
> let sessionConfiguration = URLSessionConfiguration.<wbr>default<br>
> let session = URLSession(configuration: sessionConfiguration)<br>
><br>
> print("staring sync")<br>
> queue.async(execute: {<br>
> print(">>> [\(queue.label)]: At the queue start")<br>
> print("x")<br>
> let task = session.dataTask(with: URL(string: "<a href="http://google.com" rel="noreferrer" target="_blank">http://google.com</a>")!, completionHandler: {<br>
> (data, response, error) in<br>
> print("Task ran!")<br>
> })<br>
> print("y")<br>
> task.resume()<br>
> print("z")<br>
> })<br>
> print("ending sync")<br>
><br>
> With output:<br>
><br>
> staring sync<br>
> ending sync<br>
><br>
> or...<br>
><br>
> staring sync<br>
> ending sync<br>
> >>> [com.apple.root.background-<wbr>qos]: At the queue start<br>
> x<br>
> y<br>
> y<br>
> z<br>
><br>
> Whoa.<br>
><br>
> At this point I'm going to have to confess that I need some help clarifying my model.<br>
><br>
> 1. How did point "y" get fired twice? Or how did it happen not at all?<br>
<br>
</div></div>The double-fire is something I can’t immediately come up with an<br>
explanation. It might be specific to the Linux dispatch<br>
implementation, which I’m not well versed on but it’s very strange<br>
that it would print twice. Not firing at all is likely because his<br>
snippet of code exited before the work was run on another thread. The<br>
“main” thread here either has to wait for the session work to finish<br>
explicitly, or call dispatch_main() to cede control of the main thread<br>
to the system (and subsequently exit out of the tool somewhere else).<br>
<span class=""><br>
> 2. How did my callback for dataTask *never* fire? Even if the connection task *failed* the handler<br>
ought have fired, no?<br>
<br>
</span>Likely similar to (1), though if URLSession uses runloops (Linux?)<br>
then it could also be because the runloop was never run anywhere. On<br>
Darwin I’d suspect the runloop for URLSession wasn’t running, I don’t<br>
know how it works on Linux.<br>
<span class=""><br>
> 3. I didn't want to bring this whole queue business into the<br>
> picture, but it appears that without it the program exits before the<br>
> handler has a chance to fire.<br>
<br>
</span>Probably similar to the issues in (1) and (2). If the snippet exits after running then a lot of this<br>
asynchronously scheduled work will never happen.<br>
<span class=""><br>
> 4. Changing to a queue.sync from queue.async consistently produces the output I expect, but does<br>
not fire my completionHandler still.<br>
<br>
</span>This forces the queue.sync to run in-line (on the current thread) but<br>
the snippet will then likely still exit before anything happens to<br>
cause the URLSession to finish.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
-Dave<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-users</a><br>
</div></div></blockquote></div><br></div>