So I confirmed that the sigpipe hanging my chicken program stems from the same problem - that the signal handler is not re entrant.
If I handle sigpipe, linux will send the signal when the pipe is broken. Moreover, subsequent write to the same file no. will generate another sigpipe. If the signal sent are within a very short interval, it will hang the chicken program (as demonstrated in my program below, which handle sigint) I compile the test program, then run it. % ps -C test1 PID TTY TIME CMD 17767 pts/0 00:02:09 test1 Now if I send a signal to it, I can see that it does receive that by typing "show" in the example program. % kill -s INT 17767 Now, if I send multiple signint one after another one rapidly, % kill -s INT 17767; kill -s INT 17767; kill -s INT 17767; kill -s INT 17767 This will send the chicken program into an infinite loop % top top - 13:44:47 up 11 days, 20:43, 2 users, load average: 0.65, 0.22, 0.07 Tasks: 55 total, 3 running, 52 sleeping, 0 stopped, 0 zombie Cpu(s): 98.0% us, 2.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 776088k total, 567476k used, 208612k free, 77948k buffers Swap: 2096440k total, 0k used, 2096440k free, 370976k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17767 fungsin 25 0 4916 1832 1272 R 98.5 0.2 0:55.53 test1 And it looks like chicken is still doing some gc work while subsequent signal arrives. If my guess is correct, should the gc (or any non-entrant code) be protected by a mutex or something? TIA. -- fungsin % gdb test1 17767 0xb7e9da16 in C_reclaim () from /usr/local/lib/libchicken.so (gdb) bt #0 0xb7e9da16 in C_reclaim () from /usr/local/lib/libchicken.so #1 0xb7e9e5ed in C_save_and_reclaim () from /usr/local/lib/libchicken.so #2 0xb7e4dfef in f_2787 () from /usr/local/lib/libchicken.so #3 0x0000001e in ?? () #4 0x00000005 in ?? () #5 0xb7ce3e5c in ?? () #6 0xbfdacdf4 in ?? () #7 0xbfdace04 in ?? () #8 0x0000001e in ?? () #9 0xb7eea934 in ?? () from /usr/local/lib/libchicken.so #10 0xb7cd10f8 in ?? () #11 0xb7ce3e2c in ?? () #12 0xbfdacdf4 in ?? () #13 0xb7eea934 in ?? () from /usr/local/lib/libchicken.so #14 0xb7ce3e5c in ?? () #15 0x00000005 in ?? () #16 0xb7cdfe88 in ?? () #17 0xb7e3a522 in tr4 () from /usr/local/lib/libchicken.so #18 0x0804b2e0 in ?? () #19 0xb7eea934 in ?? () from /usr/local/lib/libchicken.so #20 0x00a3fca0 in ?? () from /lib/ld-linux.so.2 #21 0x08049db8 in f_73 () #22 0xbfdace50 in ?? () #23 0xb7e9f353 in CHICKEN_run () from /usr/local/lib/libchicken.so Previous frame inner to this frame (corrupt stack?) On 5/1/08, Lui Fungsin <[EMAIL PROTECTED]> wrote: > Hi, > > I know that the chicken core is not re entrant. > In that context, what's the usual practice for writing posix signal > handler in chicken? > > See example program below. > > If you type something, it will simply echo it. > You can type 'show' to print the a global flag. > Ctrl-C will set the flag to true. > If you hit ctrl-c rapidly, you'll send it into a loop consuming 100% > cpu. (ctrl-\ to quit it) > > Am I correct that the signal handler written in scheme will be invoked > asynchronously? > How would one write this program in chicken correctly? Maybe there's a > way to do an atomic operation to set the flag? > > Thanks, > fungsin. > > (declare > (uses extras regex posix utils srfi-13)) > (require 'regex) > (require 'posix) > (require 'utils) > (require-extension loop) > > (define *user-interrupted?* #f) > > (set-signal-handler! > signal/int > (lambda (signo) > (set! *user-interrupted?* #t))) > > (loop for l = (read-line) > while (and l (not (eof-object? l))) > if (string= l "show") do > (print *user-interrupted?*) > else if (string= l "exit") do > (exit 0) > else do > (write-line l)) > _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
