[swift-users] [Swift3][Linux][URLSession]: Core dump when trying to make simple HTTP request

[Dave Abrahams]

Pasting a reply on behalf of Matt Wright (cc'd):

> On Oct 27, 2016, at 1:57 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> From: Steven Harms via swift-users <swift-users at swift.org>
> Subject: [Swift3][Linux][URLSession]: Core dump when trying to make simple HTTP request
...<schnipp 40>...
> Date: October 27, 2016 at 5:01:58 AM PDT
> To: swift-users at swift.org
> Reply-To: Steven Harms <sgharms at stevengharms.com>
> 
> 
> Hello Swift,
> 
> 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.
> 
> Inspired by this [gist][], I've written the following:
> 
> let queue = DispatchQueue.global(qos: .background)
> 
> let sessionConfiguration = URLSessionConfiguration.default
> let session = URLSession(configuration: sessionConfiguration)
> 
> print("staring sync")
> queue.async(execute: {
>     print(">>> [\(queue.label)]: At the queue start")
>     print("x")
>     let task = session.dataTask(with: URL(string: "http://google.com")!, completionHandler: {
>         (data, response, error) in
>         print("Task ran!")
>     })
>     print("y")
>     task.resume()
>     print("z")
> })
> print("ending sync")
> 
> With output:
> 
> staring sync
> ending sync
> 
> or...
> 
> staring sync
> ending sync
> >>> [com.apple.root.background-qos]: At the queue start
> x
> y
> y
> z
> 
> Whoa.
> 
> At this point I'm going to have to confess that I need some help clarifying my model.
> 
> 1. How did point "y" get fired twice? Or how did it happen not at all?

The double-fire is something I can’t immediately come up with an
explanation. It might be specific to the Linux dispatch
implementation, which I’m not well versed on but it’s very strange
that it would print twice. Not firing at all is likely because his
snippet of code exited before the work was run on another thread. The
“main” thread here either has to wait for the session work to finish
explicitly, or call dispatch_main() to cede control of the main thread
to the system (and subsequently exit out of the tool somewhere else).

> 2. How did my callback for dataTask *never* fire? Even if the connection task *failed* the handler
ought have fired, no?

Likely similar to (1), though if URLSession uses runloops (Linux?)
then it could also be because the runloop was never run anywhere. On
Darwin I’d suspect the runloop for URLSession wasn’t running, I don’t
know how it works on Linux.

> 3. I didn't want to bring this whole queue business into the
> picture, but it appears that without it the program exits before the
> handler has a chance to fire.

Probably similar to the issues in (1) and (2). If the snippet exits after running then a lot of this
asynchronously scheduled work will never happen.

> 4. Changing to a queue.sync from queue.async consistently produces the output I expect, but does
not fire my completionHandler still.

This forces the queue.sync to run in-line (on the current thread) but
the snippet will then likely still exit before anything happens to
cause the URLSession to finish.

-- 
-Dave