SlowOperationInformer.cpp:55: error: `SIGALRM' undeclared (first use this functi


I'm compiling: /usr/local/src/llvm/lib/Support/SlowOperationInformer.cpp on MinGW. However, it stops complaining about that SIGALRM is undeclared:

Henrik Bach wrote:


I'm compiling: /usr/local/src/llvm/lib/Support/SlowOperationInformer.cpp on MinGW. However, it stops complaining about that SIGALRM is undeclared:

Is there an alarm() syscall on MinGW? And if so, what signal does it send (according to the MinGW docs)?

-- John T.

Ultimately, this is another function that needs to go into lib/System. An alternate approach is to fork a thread, sleep, and when the thread wakes up, "ring the alarm".


John Criswell wrote:

There's simply no equivalent to signals on Windows. There is no way to
asynchronously interrupt a thread's processing to execute some handler.
The only thing you can asynchronously do to a thread is kill it, and
that's generally frowned upon (who knows what critical sections it might
be holding, etc...).

Stuff like alarms is supposed to be done using the "event-driven" style
of programming, using the Windows message queue, APCs or I/O completion
ports. You can do what Reid suggests below, but it begs the question of
how one "rings the alarm" in the main thread. Set a flag that's
periodically checked? Hmm... guess that's what this particular signal
handler does anyway :slight_smile: Actually, one can dispense with the extra thread
by using waitable timers and periodically checking its state, so long as
you don't plan on supporting Win95 or NT 3.1/3.5.

It definitely belongs in lib/System.

I just discovered that the *only* place this is used is in the debugger when it is loading files, etc. There should be a way to do this without an alarm. In fact, a thread could easily set the "ShouldShowStatus" every second until the the thing is cancelled. Since the caller is required to update the progress, this could also be done with time deltas without the use of threads or signals. When I get the lib/System/TimeValue abstraction implemented, I'll probably just update SlowOperationInformer to use timestamp deltas rather than signals and avoid this whole problem altogether.

Jeff Cohen wrote: