end
Если в какой-то момент выполнения метода job
, переменная $flag
станет равной true
, то в течение пяти секунд после этого потоки thread4
и thread5
гарантированно запустятся. После этого поток watcher
завершается.
В следующем примере мы ждем создания файла. Каждые 30 секунд проверяется его существование, и как только файл появится, мы запускаем новый поток. Тем временем остальные потоки занимаются своим делом. На самом деле ниже мы наблюдаем за тремя разными файлами.
def waitfor(filename)
loop do
if File.exist? filename
file_processor = Thread.new { process_file(filename) }
Thread.exit
else
sleep 30
end
end
end
waiter1 = Thread.new { waitfor('Godot') }
sleep 10
waiter2 = Thread.new { waitfor('Guffman') }
sleep 10
headwaiter = Thread.new { waitfor('head') }
# Основной поток занимается другими делами...
Есть много ситуаций, когда поток должен ожидать внешнего события (например, в сетевых приложениях так бывает, когда сервер на другом конце соединения работает медленно или ненадежно).
13.2.8. Продолжение обработки во время ввода/вывода
Часто приложению приходится выполнять одну или более длительных операций ввода/вывода. Прежде всего, речь идет о вводе данных с клавиатуры, поскольку человек печатает куда медленнее, чем вращается диск. Это время можно употребить на пользу с помощью потоков.
Возьмем, к примеру, шахматную программу, которая должна ждать, пока человек сделает ход. Конечно, мы можем изложить только сам принцип, не вдаваясь в технические детали.
Предположим, что итератор predict_move
генерирует вероятные ходы человека (и ответные ходы программы). Тогда в момент, когда человек сделает ход, не исключено, что у компьютера уже будет готов ответ.
scenario = {} # Хэш ход-ответ.
humans_turn = true
thinking_ahead = Thread.new(board) do
predict_move do |m|
scenario[m] = my_response(board,m)
Thread.exit if humans_turn == false
end
end
human_move = get_human_move(board)
humans_turn = false # Остановить поток.
# Теперь можно посмотреть, нет ли в хэше scenario хода,
# сделанного пользователем...
Конечно, настоящие шахматные программы работают не так.
13.2.9. Реализация параллельных итераторов
Предположим, что нужно параллельно обходить несколько объектов, то есть для каждого объекта найти первый элемент, потом второй, потом третий и т.д.
Рассмотрим следующий пример. Пусть compose
— имя магического метода, который выполняет композицию итераторов. Допустим еще, что у каждого объекта есть стандартный итератор each
и что каждый объект возвращает по одному элементу на каждой итерации.
arr1 = [1, 2, 3, 4]
arr2 = [5, 10, 15, 20]
compose(arr1, arr2) {|a,b| puts '#{а} и #{b}' }
# Должно быть напечатано:
# 1 и 5
# 2 и 10
# 3 и 15
# 4 и 20
Можно было бы, конечно, использовать для этой цели zip
. Но если нужно более элегантное решение, при котором все элементы не будут храниться одновременно, то без потоков не обойтись. Такое решение представлено в листинге 13.7.
def compose(*objects)
threads = []
for obj in objects do
threads << Thread.new(obj) do |myobj|
me = Thread.current
me[:queue] = []
myobj.each {|x| me[:queue].push(x) }
end
end
list = [0] # Фиктивное значение, отличное от nil.
while list.nitems > 0 do # Еще есть не nil.
list = []
for thr in threads
list << thr[:queue].shift # Удалить по одному из каждого.
end
yield list if list.nitems > 0 # He вызывать yield, если все равны nil.
end
end