Re: _SC_SIGQUEUE_MAX

[christos%astron.com@localhost (Christos Zoulas)]

In article <CA+SXE9s4bY1KLXgXUWWgdv+0_Z-baLpBg2WoEG18TfyG1YWfDg%mail.gmail.com@localhost>,
Charles Cui  <charles.cui1984%gmail.com@localhost> wrote:
>
>Let me know if there are problems. In the next several days, I will try to
>add some unit tests.
>After adding the unit tests, I will continue the work of real time signals.

They mostly look fine. I am not sure that stuff has ever been tested
this is why we need to add unit tests. I am not going to commit
them before we make sure that they work properly, and for that we
need real unit-tests.  For example, I had asked you to change the
hard-coded masks to macros... One of the reasons I did that is
because the code looks wrong, for example:

 pthread_mutexattr_gettype(const pthread_mutexattr_t *attr, int *typep)
 {
+       uintptr_t val;
+
        pthread__error(EINVAL, "Invalid mutex attribute",
            attr->ptma_magic == _PT_MUTEXATTR_MAGIC);
        
-       *typep = (int)(intptr_t)attr->ptma_private;
+       val = (uintptr_t)attr->ptma_private & ~0x00ffL;  
+       *typep = (int)val;
        return 0;
 }      


That should be & 0x00ff probably. Don't bother fixing it now, I have
created macros for all of them and fixed some other minor indentation
and whitespace nits. I will post the diffs once everything builds later.

There are a few questions:

1. Should we commit the pshared stuff now (when we don't really support
   process shared mutexes), or will that confuse 3rd party software?
2. Should there be more technical review for ad@'s priority inversion work?
3. Is the PTHREAD_STACK_MIN patch useful, or can we do better?


Best,

christos