Hacker News Reader

Comment by iainmerrick | Hacker News Reader

I still find it hard to write maintainable multi-threaded code for macOS or iOS [...] without having to worry about the minutiae of parallelism (threads, semaphores, locks, barriers, etc.).

I find this surprising, as GCD does insulate you from that low-level stuff. When you need to work with mutable data, just create a dispatch queue, and only ever access the data by dispatching a function to the queue. Both Swift and Objective-C have friendly syntax for anonymous functions that makes this lightweight and easy.

View on HN

This reads like someone who purposely missed that part of the documentation just to write this article.

I think I would have less hang ups if the author just came out and said I wanted to try using Go for multi-threaded code with Swift instead of trying to make GCD sound so confusing.

Even so, I'm glad it's been written. I didn't know you could call Go code from C code (new feature since Go 1.5 apparently) or that Swift could access compiled files with these "module map" things. I'm really glad to see they've both evolved to include useful interoperability and play nicely with other things now, and I'm glad this article shows how in a practical way.

> Swift could access compiled files with these "module map" things

That's been the case since it was released – all Swift C / ObjC interop happens at the "module" level. You write a Clang module map (if you're not using a system library which already has one), point the map at the relevant header(s), then you can import that module into your Swift code.

That said, not everything is capable of being imported (variadics, complex macros, VLA structs, and a few others).

Indeed .. things have come a long way since I tried to port IPFS to iOS ..

https://github.com/seclorum/ios-go-ipfs

It seems like there's a better way to go about this than my method. I was motivated to do this not because I don't like GCD (I still don't) but because I really like Go and IPFS and didn't think that iOS should be left out of the party.

But, looking at it again, I still don't think GCD is all that great. This seems to have been intentionally designed to be different from the way so many other systems handle the issue - or at least, different enough that its still relatively discomfiting to attempt to port something away from iOS and not just to it ...

Exactly. I get that GCD can be pain to work with, but the OperationQueue class wasn't even mentioned as an alternate.

GCD is fantastic and way better than everything on macOS before it, but it's still not a silver bullet (neither is Go).

Cocoa is incredibly fragile about the main thread, so you need to be super careful what runs in what queue. If you add KVO/bindings into the mix, it needs an extraordinary level of paranoia^Wdilligence.

> Cocoa is incredibly fragile about the main thread, so you need to be super careful what runs in what queue.

This basically just boils down to "don't touch the UI off the main thread". There are some exceptions with CoreAnimation, but other than that the main thread checker will yell at you if you do something wrong.

The main thread checker is a godsend. Enabling it + TSAN + Core Data concurrency assertions have reduced the threading bugs my team deals with to almost 0.

Anywhere we're doing something specific, we make liberal use of `dispatchPrecondition(condition: .onQueue(mySerialQueue))` or `assert(Thread.isMainThread)`.

Even in places where we are doing multithreaded UI rendering (mostly CATiledLayer), it's become a non-issue. It's a night-and-day difference compared to 5+ years ago.

> Cocoa is incredibly fragile about the main thread

That basically applies to all UI framework. At least I'm not aware about one which provides good support for accessing it from another thread.

There is obviously a reason for it, which is that UI frameworks are incredibly stateful, and trying to manipulate lots of state from multiple threads at once rarely works out well.

I think BeOS tried to and it did not went well with common threading issues poping up on BeOS apps.

Not sure if Haiku has any improvements regarding it.

Not sure what you mean when you say "common threading issues"; the entire point of the Be design was to force all threads to use message-based communication instead of shared memory for virtually all uses, and mandatory locking otherwise. It's extremely effective.

It was quite common to see BeOS apps crashing due to not handling the threads communication properly.

Having the whole OS being so multithreading heavy was a novelty for the large majority of developers and quite easy to make mistakes.

I found adopting a functional reactive programming really works well for multithreaded systems.

GCD is super great and I use it a lot (...if you had to extend AsyncTask recently: my condolences), but it doesn't safeguard you from race conditions, dealing with locks and all that fun stuff.

I don't have a lot of golang experience, but from what I can see here, golang doesn't really either: https://tour.golang.org/concurrency/1

Channels seem like a simple thread safe stream for the most part, which you can get with Rx.

This is correct, golang doesn't give you thread safety for free. Values passed via channels are safe as they're implicitly locked (i.e. it's a blocking threadsafe queue), and there are happens-before semantics for starting a goroutine, otherwise you're on your own (explicit locks / atomics / lock-wrappers like sync.WaitGroup). E.g. variable assignment isn't even atomic.

Reply on news.ycombinator.com