????? ???????????? <olga.kryzhanovska at gmail.com> wrote:
> Why should this be binary incompatible? The number of real time
> signals is _dynamic_, see getconf RTSIG_MAX. The value of RTSIG_MAX is
> defined as _tunable_ and may vary between installations of the same
> operating system. I sounds you don't know how POSIX real time signals
> work.
Fast guesses do not help and you demonstrated several times in the past
already that you failed this way...
On the other side, you support contradicting arguments:
- You claim that people _need_ more RT signals
- You claim that people will be able to write code that dynamically
adopts to a lower number of RT signals. This proves that the software
in question would be able to deal with less RT signals. So wy do you
need more RT signals at all?
I am still missing any argument from the people who like to extend the number
of RT signals.
Singnals are not a fast mechanism, so it seems to be wise to avoid them. I
remember that I wrote an "event count" mechanism for the Solaris kernel in
1995 in order to be able to have an extremely fast process synchronization
mechanism. This was done because signals are way too slow... 1.5 years later,
Sun came up with user space mutexes that offer a similar speed to what I
implemented using event counts.
I an still not convinced that there really is a need for a huge number of RT
signals, it rather seems that some people wrote code without finding the best
solution.
If you like to let a process or thread block until an event occurs, you need
user space mutexes.
If you like to send asynchronous notifications to the process you need a single
singnal and if you like to signal distinct reasons for that asynchronous event,
you may use a piece of process/thread specific shared memory that offers even
more space for descriptions than a single signal number does.
The only remaining argument is software compiled for Linux that asumes that
there are more RT signals. Even here, you gave an argument against real a demand
for more RT signals: The number of RT signals is dynamic, so a program that does
not properly deal with a lower number of RT signals could be called "buggy".
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
