Re: Support for i386 builds of glibc?

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Mon, 4 Mar 2013, David Miller wrote:

> >  I think "can't" is too strong a statement, signals are to userland what 
> > interrupts are to the kernel.  The whole critical section could run with 
> > all signals blocked; if you wrote that the overhead might be prohibitive, 
> > then I would agree though.
> 
> You can't mess with signal state in the lock handlers, think about
> siglongjmp and friends.
> 
> It's impossible even if you're willing to accept prohibitive cost.

 I don't believe it.  Can you provide me with an example where a sequence 
like:

({
  int result;

  block_signals ();
  while (!take_spinlock (&cmpxchg_lock))
    {
      restore_signals ();
      do_backoff ();
      block_signals ();
    }
  result = do_cmpxchg_manually (atomic_var, value);
  release_spinlock (&cmpxchg_lock);
  restore_signals ();
  result;
})

would not work as a (slow) replacement for:

({
  int result;

  result = do_cmpxchg (atomic_var, value);
  result;
})

where the latter statement is really a single machine instruction (CMPXCHG 
with atomic_var and value/result as its arguments)?

 I fail to see where siglongjmp or friends could come into picture here, 
the single CMPXCHG instruction being replaced has nothing to do with them 
and the state of the signal mask remains unchanged outside either 
statement above.

  Maciej