I found this code in gensigset.inc and signals.inc fpc source library.
Is this what we are talking about?

function FPSigaction(
sig: cint;
act: psigactionrec;
oact: psigactionrec
):cint;

function fpsigemptyset(var nset : tsigset):cint;
var i :longint;
Begin
for i:=0 to wordsinsigset-1 DO nset[i]:=0;
fpsigemptyset:=0;
End;

And:

type
sigset_t = array[0..wordsinsigset-1] of cuLong;
tsigset = sigset_t;
sigset = sigset_t;
psigset = ^tsigset;

  psiginfo = ^tsiginfo;
  tsiginfo = record
       si_signo : longint;
       si_errno : longint;
       si_code : longint;
       _sifields : record
           case longint of
              0 : ( _pad : array[0..(SI_PAD_SIZE)-1] of longint );
              1 : ( _kill : record
                   _pid : pid_t;
                   _uid : uid_t;
                end );
              2 : ( _timer : record
                   _timer1 : dword;
                   _timer2 : dword;
                end );
              3 : ( _rt : record
                   _pid : pid_t;
                   _uid : uid_t;
                   _sigval : pointer;
                end );
              4 : ( _sigchld : record
                   _pid : pid_t;
                   _uid : uid_t;
                   _status : longint;
                   _utime : clock_t;
                   _stime : clock_t;
                end );
              5 : ( _sigfault : record
                   _addr : pointer;
                end );
              6 : ( _sigpoll : record
                   _band : longint;
                   _fd : longint;
                end );
           end;
    end;

On 02/09/2015, Edward Bartolo <edbarx@???> wrote:
> Quote: "This means the GUI/ frontend
> either needs to handle SIGCHLD in order to get notified when a child
> process terminates so that a suitable wait call (which doubtlessly exists in
> the
> Free Pascal libraries) can be used to get rid of the zombie without
> having to wait for it or (the by far most simple solution), it (the GUI)
> needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies
> won't even be created."
>
> Aha, that gave me an idea, thanks for that. I can use the signal of
> the arrival of a new zombie as the time at which to re-enable grayed
> out buttons.
>
> The benefit of all this: very little changes to code and no
> multi-threading complications.
>
> Thanks. :D
>
> On 02/09/2015, Rainer Weikusat <rainerweikusat@???> wrote:
>> Edward Bartolo <edbarx@???> writes:
>>
>> [...]
>>
>>> The idea is this: the backend would be converted into some sort of a
>>> daemon exporting one function and importing another one. The frontend
>>> would use the exported function from the backend to send it commands.
>>> The backend would do the same thing with the exported function from
>>> the frontend:
>>>
>>> Visually, this is as follows:
>>>
>>> Frontend -------------->> Backend
>>> Frontend <<-------------- Backend
>>
>> This is not possible because functions can't be 'exported' in this way
>> (OTOH, the whole backend - frontend split is pretty pointless, anyway
>> ...)
>>
>>> In my humble opinion, this may help getting rid of having to use
>>> multithreading to avoid temporary frontend deadlocks.
>>
>> As I already explained to you quite some times: There is no such
>> need. You just have to stop fighting the API for dealing with deceased
>> subprocesses and start using it instead. This means the GUI/ frontend
>> either needs to handle SIGCHLD in order to get notified when a child
>> process terminates so that a suitable wait call (which doubtlessly exists
>> in
>> the
>> Free Pascal libraries) can be used to get rid of the zombie without
>> having to wait for it or (the by far most simple solution), it (the GUI)
>> needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies
>> won't even be created.
>> _______________________________________________
>> Dng mailing list
>> Dng@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>