Consider the following program:

#include <signal.h>

volatile int finished;

void brkhandler()
{
  printf("Ctrl-C, huh?\n");
  finished++;
  signal(SIGINT, &brkhandler);
}

main()
{
  int count;
  signal(SIGINT, &brkhandler);
  finished = 0;
  count = 50000000;
  while (count >= 0) count--;
  printf("Ctrl-C pressed %d times\n", finished);
  return 0;
}

Pressing ctrl-C once during the execution of the program prints as expected:
	Ctrl-C, huh?
	Ctrl-C pressed 1 times

Pressing ctrl-C twice (at 1 sec interval) prints:
	Ctrl-C, huh?	   [first ctrl-C]
			   [nothing is printed after second ctrl-C]
	Ctrl-C pressed 1 times
	^C		   [this seems to be printed by DOS]

It looks as if the second ctrl-C did not generate the SIGINT signal,
even though it did not terminate the program either.
I don't think this is the classic race condition between signal delivery
and the call to signal() in the sighandler, because it happens even if the 
two ctrl-C are well separated (1 second delay). 

[The DPMI host used is Windows 3.1, in case it matters.]

This program works as V2 is designed, which probably needs a bit of
explaination.  Because of the design of DPMI, it is impossible to
transfer control from a hardware interrupt or real-mode call back.
When an external event occurs, we have to get the program's attention
somehow (so control can be re-directed).  This is done in V2 by 
making any memory access to the program space generate a fault.
This test program does not touch any memory while waiting, so only
sees a single pending CTRL-C at the end of the loop.  In virtually
any real program, you will touch memory occasionally and then be
re-directed.
If you compile the program without optimization, you see it works as
intended.  If you make the decrement wait count a volatile
variable, it will also work.  You just have to touch memory!

Thank you for the explanation of how signals are implemented in DJGPP.
However, I'm afraid this does not explain what happens.
The program was actually compiled without -O, and accesses the stack twice at
each iteration (I checked that with gcc -S). Making more memory accesses
inside the loop, as you suggested, did not change the observed behavior.
Besides, the first ctrl-C is perfectly well detected; it's only the
following ctrl-C's that got ignored till the next I/O operation.

Try it with beta 4.  Your test program worked fine for me with my
patched beta 3 area.  If it doesn't work with beta 4, I'm at a loss to
explain it.

I have just tried with beta 4 and everything works as expected. Great!
Many thanks for the fix.