[fpc-devel] Linux Signals

Andrew Brunner andrew.t.brunner at gmail.com
Sat Jan 1 18:27:28 CET 2011

I'm trying to get signals to work with sockets under x64 Ubuntu 10.10
(all updates)

I installed two handlers for two events SIGIO, and SIGHUP uising
fpsigaction(SIGIO, @saAct, nil) .  I was expecting to get a byte by
byte signal under telnet to my server instance (110-pop3) on the IO
but had only received the signal on CRLF.  Firefox on the HTTP has the
same problem but I suspect a problem since it is impossible to ever
receive a signal for binary protocols having no CRLFs for as kernel
triggers to signal applications. Perhaps this particular issue is
better directed at Debian?

Another important thing is that (IMO) the data structure for
TSigAction is out-dated.

Please refer to rtl/linux/signal.inc and compare the struct with the
one specified at the URL I included for linux...  The two structs are


There are two issues.

  Problem 1: How do I control the circumstances in which the signal is
sent... To emulate conditions like windows... Which is every few
seconds until the buffer is emptied for that socket descriptor.
  Problem 2: Info.FD =0.  I did a trace into the callbacks and found
that the socket handle was stored in the si_status field of the
siginfo at runtime.  To me, this seems problematic but I guess if it's
not attributed to the discrepency in the declaration of SigInfo, I'm
looking for an approval to use this si_status as my socket number
across linux distros - or is this just a Ubuntu fluke, and under say
Red Hat I will receive my socket handle on the FD attribute !?!

 The siginfo_t argument to sa_sigaction is a struct with the following
(as interpreted by me)

  TSigVal = record
      case longint of
         0 : ( sival_int : longint );
         1 : ( sival_ptr : pointer );
    si_signo  : integer;     // Signal number */
    si_errno  : integer;     // An errno value */
    si_code   : integer;    // Signal code */
    si_trapno : integer;    // Trap number that caused
hardware-generated signal (unused on most architectures) */
    si_pid    : pid_t;        // Sending process ID */
    si_uid    : uid_t;        // Real user ID of sending process */
    si_status : integer;    // Exit value or signal */
    si_utime  : clock_t;    // User time consumed */
    si_stime  : clock_t;    // System time consumed */
    si_value  : TSigVal;   // Signal value */
    si_int    : integer;       // POSIX.1b signal */
    si_ptr    : pointer;       // POSIX.1b signal */
    si_overrun : integer;   // Timer overrun count; POSIX.1b timers */
    si_timerid :integer;     // Timer ID; POSIX.1b timers */
    si_addr    : pointer;    // Memory location which caused fault */
    si_band    : longInt;    // Band event (was int in glibc 2.3.2 and
earlier) */
    si_fd      : integer;      // File descriptor */
    si_addr_lsb:shortint;   // Least significant bit of address (since
kernel 2.6.32) */

I'm asking anyone with signals and socket experience to take a look at
this.  I can follow-up with a sample fp program if necessary...

More information about the fpc-devel mailing list