Depends on how they define it, and how old systems they have
tried..
> don't have the knowledge to know how SIGURG is supposed to work, but
> apparently its only delivered once for a given process on a linux system,
> while it is delivered as often as signaled for a Solaris system. Does this
> make *any* sense? I had a read thru the code in the kernel around signals,
> but could not see any place where the URG signal is handled differently from
> say, a WINCH or anything else.
Considering only signals which a process can catch and process.
(E.g. not about KILL or STOP or CONT ...)
*ANY* classical signal in *ANY* UNIX is "unrealiable". You will
get them, unless given signal is already in execution in which
case no more of same signal are sent while that execution lasts..
Once previous signal S processing has completed, same process can
receive again a signal S.
That is, you will get SIGURG, but you will not get guaranteed
info that there was only one SIGURG coming to your way.
(There may have been dozens during that processing.)
> Can anyone explain to me the use/intended use of the URG signal. I
> personally had never heard of it, but my database vendor claims that its not
> reliable on Linux. They are using it to deliver "Stop sending me data" from
> api clients to their database.
"URG" -- It relates to IO events - some platforms call it SIGPOLL.
It does not carry supplementary data, e.g. "who" (which fd) caused
this event.
There are then things called Queued Signals, which (to certain
extent) will guarantee delivery of the signal in question even
while same signal is already blocking -- the queue is not of
infinite length.. They can also deliver supplementary data.
At this list there has been recent talk about how to poll
16000 fd's at single process - effectively.
> --
> Jay Thorne jay@result.com Geek at large jthorne@globalmedia.com
/Matti Aarnio <matti.aarnio@sonera.fi>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/