Назовите recv () на том же сокете блокирования от двух потоков
Вы захотите воспользоваться тем, что можете легко преобразовать строку в массив. В вашем случае вы собираетесь использовать jQuery (или ванильные js, такие как getElementById ()), чтобы захватить текст, который вы хотите стилизовать, а затем использовать javascript, чтобы перебрать строку и назначить новый цвет каждому.
Например:
var a = $("h1").text();
$("h1").empty();
for(var i = 0; i < a.length; i++){
$("h1").append(""+a[i]+"");
}
4 ответа
Один поток получит его, и нет никакого способа сказать который.
Это не походит на разумный дизайн. Есть ли причина, почему Вам нужны два вызова потоков recv() на том же сокете?
Реализации сокета должны быть ориентированы на многопотоковое исполнение, таким образом, точно один поток должен получить данные, когда это становится доступным. Другой вызов должен просто заблокироваться.
Я не могу найти ссылку для этого, но здесь являюсь моим пониманием:
Гарантия поставщика потокобезопасности может означать только, что несколько потоков могут каждый безопасно использовать свои собственные сокеты; это не гарантирует атомарность через единственный вызов, и это не обещает никакого конкретного выделения данных сокета среди нескольких потоков.
Предположим распараллеливают вызовы recv () на сокете, в котором это получает потоковую передачу данных TCP на высоком показателе. Если recv () должен быть атомарным вызовом, затем распараллелить A, мог бы заблокировать все другие потоки от выполнения, потому что это должно работать непрерывно для получения по запросу во всех данных (пока его буфер не полон, так или иначе.), Который не был бы хорош. Следовательно, я не предположил бы, что recv () неуязвим для контекстного переключения.
С другой стороны предположите, что поток A выполняет блокирующийся вызов к recv () на сокете TCP, и данные входят медленно. Следовательно вызов к recv () возвращается с набором errno к EAGAIN.
В любом из этих случаев предположите, что поток B называет recv () на том же сокете, в то время как поток A все еще получает данные. Когда действительно распараллеливает данные получения остановки, врученные ему так, чтобы поток B мог начать получать данные? Я не знаю о реализации Unix, которая попытается помнить, что поток A был посреди операции на сокете; вместо этого, это до приложения (распараллеливает A и B) согласовывать их использование его.
Обычно лучше разрабатывать приложение так, чтобы только один из потоков назвал recv () на единственном сокете.
Из страницы справочника на recv
recv () на сокете SOCK_STREAM возвраты столько же доступной информации сколько размер предоставленного буфера может содержать.
Позволяет предполагают, что Вы используете TCP, так как он не был указан в вопросе. Поэтому предположите, что Вы имеете поток A и распараллеливаете B оба блокирования на recv () для сокета s. После того как s имеет некоторые данные, которые будут получены, это разблокирует один из потоков, позволяет, говорят, что A, и возвращают данные. Возвращенные данные будут иметь некоторый случайный размер, что касается нас. Поток A осматривает полученные данные и решает, имеет ли это полное "сообщение", где сообщение является понятием прикладного уровня.
Поток A решает, что не имеет полного сообщения, таким образом, он называет recv () снова. НО тем временем B уже блокировался на том же сокете и получил остальную часть "сообщения", которое было предназначено для потока A. Я использую предназначенный свободно здесь.
Теперь оба потока A и поток B имеют неполное сообщение, и будет, в зависимости от того, как код написан, выбросьте данные как недопустимые, или вызовите странные и тонкие ошибки.
Мне бы хотелось сказать, что не знал это на основе опыта.
Таким образом, в то время как recv () сам технически ориентирован на многопотоковое исполнение, это - плохая идея иметь два потока, называя его одновременно при использовании его для TCP.
Насколько я знаю, что абсолютно безопасно при использовании UDP.
Я надеюсь, что это помогает.