Еще раз акцентирую внимание читателей (видимо в статье не получилось поставить этот акцент), OmniThreadLibrary предоставляет гораздо более высокоуровневый подход к написанию многопоточного кода по сравнению с WinAPI и обертками типа TThread. Из приведенных выше примеров (какими бы примитивными они ни были) видно, что ни методов создания/уничтожения потоков, ни функций ожидания/синхронизации явным образом вызывать не нужно, все спрятано за очень красивыми и удобными абстракциями.
Embarcadero Delphi XE/XE2 качественные, удобные, современные продукты. «Дельфи покатился по наклонной» можно было говорить этак году в 2006-м, но уж точно не сейчас.
TThread никуда не девается. TThread — это обертка над базовыми WinAPI функциями. Более того, на нижнем уровне библиотека OTL класс TThread успешно используется. Здесь же речь идет об уровнях гораздо более высоких по сравнению с TThread. Вы попробуйте сначала реализовать на основе голого TThread, например, конвейер (Pipeline) и тогда поймете, в чем разница.
Жаль, что не могут напрямую, это ускорило бы обмен данными в 2 раза как минимум (для ситуаций когда обмен происходит между двумя беспроводными устройствами, ни одно из которых не является точкой доступа).
>>К организации самой беспроводной сети тоже можно подойти более обстоятельно
Согласен, если затратить определенные усилия может получиться что-то лучшее. Описанное мной решение хорошо тем, что оно дешевое и работает практически из коробки. 2500 р. роутер + 800 р. WiFi адаптер + 3500 р. медиаплеер = 6800 руб. за все удовольствие + стоимость диска для хранения контента.
Человек разобрался в электронике и сделал работающий образец «на коленке». Я думаю, мало кто из местного населения способен на это. Я в их числе, как, думаю, и вы. И пусть тут нет «теоретической» новизны, зато когда создатель устройства пойдет работать, он реально сможет смастерить что-то новое и полезное.
>>что пинг в 5 раз с подключенным жестким к кинетику взлетает, вас не смущает?
я такого не заметил, надо перетестировать. Даже если и так, для ночных скачиваний это неактуально — я все равно сплю, Инетом в это время никто не используется :)
>>с нормальных трекеров без учета ратио.
Рутрекер кстати уже перестал учитывать рейтинг, если что.
Вопрос в том, где находился этот файл — если на компьютере, подключенном к роутеру проводами — то все ОК. Если на диске, подключенном к роутеру по USB — будут тормоза.
Предлагаю один из «странных», но рабочих вариантов оптимизации (кому-то этот способ может показаться быдлокодерским). Поскольку в клиент-серверных системах данные на клиенте вне транзакций можно всегда считать неактуальными (на сервере они уже могли измениться), то на клиенте можно реализовать логику «не запрашивать заданный справочник у сервера чаще чем 1 раз в N секунд» (ну или миллисекунд — в зависимости от того, как часто клиентский код может запросить актуальную версию справочника у сервера).
Такой вариант позволяет в клиентском коде не беспокоиться (не думать) о сокращении количества обращений за актуальной версией справочника — слишком частые вызовы просто будут проигнорированы промежуточным слоем клиента, обращений к серверу при этом не будет вообще.
Согласен, если затратить определенные усилия может получиться что-то лучшее. Описанное мной решение хорошо тем, что оно дешевое и работает практически из коробки. 2500 р. роутер + 800 р. WiFi адаптер + 3500 р. медиаплеер = 6800 руб. за все удовольствие + стоимость диска для хранения контента.
А вообще, в России уже есть Raspberry Pi?
я такого не заметил, надо перетестировать. Даже если и так, для ночных скачиваний это неактуально — я все равно сплю, Инетом в это время никто не используется :)
>>с нормальных трекеров без учета ратио.
Рутрекер кстати уже перестал учитывать рейтинг, если что.
Такой вариант позволяет в клиентском коде не беспокоиться (не думать) о сокращении количества обращений за актуальной версией справочника — слишком частые вызовы просто будут проигнорированы промежуточным слоем клиента, обращений к серверу при этом не будет вообще.