6 ms·

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, semaph

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.

tannedNerd 8y ago
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.
- sephoric 8y ago
  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.
  - favorited 8y ago
    > 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).
  - mmjaa 8y ago
    Indeed .. things have come a long way since I tried to port IPFS to iOS .. https://github.com/seclorum/ios-go-ipfs 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 ...
- tylerflick 8y ago
  Exactly. I get that GCD can be pain to work with, but the OperationQueue class wasn't even mentioned as an alternate.
tabs_masterrace 8y ago
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.
- woolvalley 8y ago
  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 https://tour.golang.org/concurrency/1 Channels seem like a simple thread safe stream for the most part, which you can get with Rx.
  - Groxx 8y ago
    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.
pornel 8y ago
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.
- saagarjha 8y ago
  > 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.
  - favorited 8y ago
    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.
- Matthias247 8y 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.
  - pjmlp 8y ago
    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.

tannedNerd 8y ago

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.

sephoric 8y ago
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.
- favorited 8y ago
  > 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).
- mmjaa 8y ago
  Indeed .. things have come a long way since I tried to port IPFS to iOS .. https://github.com/seclorum/ios-go-ipfs 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 ...
tylerflick 8y ago
Exactly. I get that GCD can be pain to work with, but the OperationQueue class wasn't even mentioned as an alternate.

tabs_masterrace 8y ago

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.

woolvalley 8y ago
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 https://tour.golang.org/concurrency/1 Channels seem like a simple thread safe stream for the most part, which you can get with Rx.
- Groxx 8y ago
  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.

pornel 8y ago

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.

saagarjha 8y ago
> 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.
- favorited 8y ago
  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.
Matthias247 8y 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.
- pjmlp 8y ago
  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.