A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2006-September/068762.html below:

[Python-Dev] Signals, threads, blocking C functions

[Python-Dev] Signals, threads, blocking C functionsAdam Olsen rhamph at gmail.com
Wed Sep 13 01:03:54 CEST 2006
On 9/12/06, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
> On 9/12/06, Adam Olsen <rhamph at gmail.com> wrote:
> > My previous mention of using a *single* flag may survive corruption
> > simply because we can tolerate false positives.  Signal handlers would
> > write 0xFFFFFFFF, the poll loop would check if *any* bit is set.  If
> > so, write 0x0, read off the fd, then loop around and check it again.
> > If the start of the read() acts as a write-barrier it SHOULD guarantee
> > we don't miss any positive writes.

> PyErr_CheckSignals()
> {
>   if (signal_flag) {
>      char signum;
>      signal_flag = 0;
>      while (read(signal_pipe_r, &signum, 1) == 1)
>          process_signal(signum);
>   }
> }

The more I think about this the less I like relying on read() imposing
a hardware write barrier.  Unless somebody can say otherwise, I think
we'd be better of putting dummy
PyThread_aquire_lock/PyThread_release_lock calls in there.

-- 
Adam Olsen, aka Rhamphoryncus
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4