Re: Synchronization primitives in UML (was: Re: [uml-devel] Re: [patch 09/20] uml: use SIG_IGN for empty sighandler)

[Blaisorblade <blaisorblade_spam@yahoo.it>]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

On Saturday 06 November 2004 06:13, Jeff Dike wrote:
> On Fri, Nov 05, 2004 at 08:36:55PM +0100, Blaisorblade wrote:
> > Also, why shouldn't sigprocmask be restartable with the -ERESTART*
> > mechanism?

> Err, that was pause, not sigprocmask.  sigprocmask just switches the signal
> mask.
Ok, I saw it able to return EINTR, so I thought you wanted it to bounce back 
there (I wasn't understanding the purpose of the code anyway, now with your 
help it's clear).
> pause is what sits there and waits for something to happen.

> > Wouldn't your kludge break?

> What kludge?
[...]
> You're seeing races where there aren't any.  SIGWINCH is only possible when
> it gets a controlling tty, which happens after the sigprocmask.
When writing this I was still thinking to sigprocmask() getting SIGWINCH, not 
pause. So obviously I said nonsense.

I also understand now what all this is for. When I have time for this, I'll at 
least copy and paste your mail into a comment, with any needed adjustment.

For the semaphore issue, I have some ideas (like using futexes) which need to 
be developed a bit:

1) I want to create a semaphore API in os_*.
2) It will be able to use socketpairs.
3) It will be able to use futexes, if they are non-persistant and usable 
without too much issues (the same way we are going to support Async I/O).
4) It will be used first by the code which could really benefit from the 
performance increase.
5) It won't use persistant objects.

Any comment on these issues? Also, apart TT context switching, is there any 
other performance-sensitive use of semaphores, which would benefit from using 
futexes?

About this:
> A more basic issue is the interface.

> What I have now is the mapping 
>  open <-> create
>  read <-> down
>  write <-> up
>  close <-> destroy
> which is way simpler and cleaner than semget, semop, and ??? (I can't
> figure out how to destroy one of these things).

Yes, semget and friends are uglier.

But don't think that the current nested code is simple to read - three 
semaphores at a time, without a clear name, are not the clearer code on the 
world.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]