Правильный способ настройки NSStreams? - PullRequest
0 голосов
/ 10 декабря 2018

Я пишу небольшое одноранговое приложение для чата Bluetooth.В настоящее время я делаю следующее:

let thread = Thread(block: { [weak self] in
    guard let `self` = self else { return }

    self.channel.inputStream.delegate = self
    self.channel.inputStream.schedule(in: .current, forMode: .defaultRunLoopMode)
    self.channel.inputStream.open()

    self.channel.outputStream.delegate = self
    self.channel.outputStream.schedule(in: .current, forMode: .defaultRunLoopMode)
    self.channel.outputStream.open()

    RunLoop.current.run()
})

thread.start()

Где self.channel равно CBL2CAPChannel Проблема, с которой я сейчас сталкиваюсь, заключается в том, что она генерирует новый поток для каждой пары каналов, и в конечном итоге их становится слишком много.

Как правильно настроить CBL2CAPChannel с в этом случае?Документы Apple используют основной поток для этого, что является неожиданным и может привести к проблемам при большом количестве соединений.

1 Ответ

0 голосов
/ 10 декабря 2018

Документы Apple используют для этого основной поток, что является неожиданным и может привести к проблемам при большом количестве подключений.

Это не неожиданно;это совершенно нормально.Вы не должны создавать отдельные потоки для каждого потока.Весь смысл циклов выполнения состоит в том, чтобы обрабатывать параллелизм без создания новых потоков.В программировании цикла выполнения вы очень редко создаете новые потоки.Программирование цикла выполнения возникло задолго до многоядерных систем и было разработано для совместной многозадачности (а не вытесняющей многозадачности).

Даже если вы хотите перенести вещи на другие ядра, вы никогда не должны создавать Threadобъект, если вы не взаимодействуете с кодом C ++, который требует этого.Не было много веских причин использовать NSThread напрямую в течение почти десятилетия. Передача работы в GCD с использованием DispatchQueue. Передача данных из потока в другую очередь отправки для обработки - это очень нормальный подход, при котором практически вся работа удаляется из основной очереди (тогда основная очередь простовыполняет координацию).

Если у вас большое количество соединений или они очень заняты, то вы можете рассмотреть возможность размещения всех из них в отдельном потоке (не один поток на соединение;одна нить всего).Но маловероятно, что при ставках L2CAP вам придется это делать.Я создал приложения для чата Mac для G4s, менее мощные, чем iPhone 5 с одним потоком.

...