Hello list !

I'm using Thread.delay on a unix platform, and sometimes it seams that
the thread that called Thread.delay is killed because it did not catch
the exception that seams to be raised from the delay :

Thread 1 killed on uncaught exception Unix.Unix_error(11, "select", "")
Raised at file "thread.ml", line 60, characters 23-50

This happens frequently when I run the program with gprof (since gprof
uses an alarm signal apparently). Here is the relevant section of
strace, showing the delay as a select with timeout and the gprof signal
:

32506 select(0, [], [], [], {0, 2153})  = 0 (Timeout)
32506 select(0, [], [], [], {0, 2647})  = 0 (Timeout)
32506 select(0, [], [], [], {0, 2030})  = ? ERESTARTNOHAND (To be restarted)
32506 --- SIGPROF (Profiling timer expired) @ 0 (0) ---
32506 rt_sigreturn(0x1b)                = -1 EINTR (Interrupted system call)
32506 write(2, "Thread 1 killed on uncaught exce"..., 72) = 72
32506 write(2, "Raised at file \"thread.ml\", line"..., 54) = 54

The problem I have with this, is that in my opinion this is not a
correct behavior for the Thread.delay function : This underlying select
should handle EINTR internaly, and it seams wrong to me to have to "try"
Thread.delay in my program.

What do you think ?
Should I fill a bug ?