This problem is specific to all releases, and fedora, up
to rawhide.

A simple test case is:
---%<---
#!/bin/ksh
toto="s"
alarm -r alarm_handler +1
function alarm_handler.alarm
{
if [[ $toto == "s" ]]
then
toto="e"
else
toto="f"
fi
}
IFS=","
(echo "2";sleep 1;echo "3") | while IFS="," read  arg1
#(echo "2";sleep 1;echo "3") | while  read  arg1
do
print "$arg1"
done
---%<---

There is a small thread about it at
http://lists.research.att.com/pipermail/ast-users/2014q4/004684.html

I had made an initial one liner patch that address
specifically the problem, but I was not happy with
it because it probably would just hide other issues
that may arise from alarms.

Anyway, I will only propose a simple patch for
cases where there are no exceptions involved.

This was an off list reply I received:
---%<---
[...]
Subject: Re: [ast-users] [PATCH] Problem with alarm and IFS
From: David Korn <dgkorn>
To: =?UTF-8?Q?Paulo_C=C3=A9sar_Pereira_de_Andrade?= <paulo.cesar.pereira.de.andrade>
Content-Type: multipart/alternative; boundary=001a113ab2ba6fd291050a9c0dcd

--001a113ab2ba6fd291050a9c0dcd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I never documented the alarm builtin because it is problematic.  The
problem is that traps can't safely be handled asynchronously.  What should
happen is that the trap is marked for execution (sh_trapnote) and run after
the current command completes.  The time trap should wake up the shell if
it is blocked and it should return and then handle the trap.

That being said, I will pick up both of our patches since they don't do
harm and improve the undocumented alarm builtin.
[...]
---%<---