No subject

Tue Dec 2 04:10:01 GMT 2003

"When a signal is generated by the sigqueue() function or any
signal-generating function that supports the specification of
an application-defined value, the signal is marked pending and,
if the SA_SIGINFO flag is set for that signal, the signal is
queued to the process along with the application-specified signal
value. Multiple occurrences of signals so generated are queued in
FIFO order."

The sysconf variable for the number of queued signals is :

SIGQUEUE_MAX           _SC_SIGQUEUE_MAX       Maximum number of
                                               queued signals that a
                                               process may send and
                                               have pending at the
                                               receiver(s) at any

Signals under this limit are guarenteed to be queued. Now if this
is less than the number of open and oplocked files per smbd then
we are safe. I'm trying to track down numbers for this on various
systems so we can judge. But note this number will be easy to
increase - so making it equal to the number of file descriptors
available per process guarentees that we will never lose a message.

> Jordan cites the endless vendor wars of the 80s, but doesn't mention
> the equally disastrous series of "good ideas" (think 'streams') that
> got pushed as standards and still live on to haunt us today.  Both
> are perspectives worthy of consideration.

Jordan is right. API compatibility is king. Without it,
ISV's ignore your platform. Just look at the trouble you're
having with Samba, a Free Software project - in getting us
to support your particular API in addition to the Linux one.
Other ISV's would just ignore you.


More information about the samba-technical mailing list