Побочное разблокирование в потоке повышения

Мне пришлось автоматизировать весь процесс заполнения формы, и теперь он, кажется, работает просто отлично.

def get_image(self, response):
        # inspect_response(response, self)
        item = response.meta['item']
        url = 'http://oris.co.palm-beach.fl.us:8080/PdfServlet/PdfServlet27'
        headers = {   
                            'Connection': 'keep-alive',
                            'origin': "http://oris.co.palm-beach.fl.us",
                            'upgrade-insecure-requests': "1",
                            'dnt': "1",

                            'user-agent': "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36",
                            'accept': "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3",
                            'cache-control': "max-age=0",
                            'Accept-Encoding': 'gzip,deflate',
                        }

        body={}
        # Generate body from form
        for  i in response.xpath("//form[@name='courtform']/input"):
            name = i.xpath(".//@name").extract_first()
            val = i.xpath(".//@value").extract_first()
            body[name] =  val
        # Remove watermakr from PDF   
        body['WaterMarkText'] = '0'

        me = MultipartEncoder(fields=body, boundary='----WebKitFormBoundarygGHghpHs08goICxO')
        me_body = me.to_string()

        headers['Content-Type'] =me.content_type




        yield scrapy.Request(url, method = 'POST',  body = me_body,  callback = self.get_pdf, headers = headers, meta={'item' : item})
10
задан 1800 INFORMATION 9 March 2009 в 08:08
поделиться

2 ответа

Эта статья Anthony Williams особенно подробно изложена.

Побочные следы не могут быть предсказаны: они чрезвычайно случайны с точки зрения пользователя. Однако они обычно происходят, когда библиотека потока не может надежно гарантировать, что поток ожидания не пропустит уведомление. Так как пропущенное уведомление представило бы бесполезную условную переменную, библиотека потока будит поток от своего ожидания, а не рискнуть.

Он также указывает, что Вы не должны использовать timed_wait перегрузки, которые берут продолжительность, и необходимо обычно использовать версии, которые берут предикат

Это - ошибка новичка, и один это легко преодолено с простым правилом: всегда проверяйте свой предикат в цикл при ожидании с условной переменной. Более коварная ошибка прибывает из timed_wait ().

Эта статья Vladimir Prus также интересна.

Но почему делают нам нужен цикл с условием продолжения, не можем мы писать:

if (!something_happened)
  c.wait(m);

Мы не можем. И уничтожающая причина состоит в том, что 'ожидание' может возвратиться ни с кем, 'уведомляют' вызов. Это назвало побочное пробуждение и явно позволяется POSIX. По существу возвратитесь из 'ожидания', только указывает, что совместно используемые данные, возможно, изменились, так, чтобы данные были оценены снова.

Хорошо, итак, почему это еще не фиксируется? Первая причина состоит в том, что никто не хочет зафиксировать его. Обертывание вызова для 'ожидания' в цикле очень желаемо по нескольким другим причинам. Но те причины требуют объяснения, в то время как побочное пробуждение является молотком, который может быть применен к любому студенту первого курса бесперебойно.

11
ответ дан 3 December 2019 в 23:51
поделиться

Это сообщение в блоге объясняет Linux, с точки зрения futex возврат системного вызова, когда сигнал поставляется процессу. К сожалению, это не объясняет ничто больше (и действительно спрашивает для получения дополнительной информации).

Статья в Википедии о побочных пробуждениях (которые, кажется, posix-широкое понятие, btw, не ограниченный повышением) может заинтересовать Вас также.

2
ответ дан 3 December 2019 в 23:51
поделиться
Другие вопросы по тегам:

Похожие вопросы: