Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-Id: <5.0.0.25.0.20001211233737.02885010@pop.bresnanlink.net> X-Sender: cabbey AT pop DOT bresnanlink DOT net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 12 Dec 2000 00:54:02 -0600 To: cygwin AT cygwin DOT com From: Chris Abbey Subject: Re: [long] Re: signals? In-Reply-To: <20001212002741.D22048@redhat.com> References: <5 DOT 0 DOT 0 DOT 25 DOT 0 DOT 20001211202412 DOT 02930eb0 AT pop DOT bresnanlink DOT net> <4 DOT 3 DOT 2 DOT 7 DOT 0 DOT 20001113000139 DOT 00c3ba60 AT pop DOT bresnanlink DOT net> <4 DOT 3 DOT 2 DOT 7 DOT 0 DOT 20001001212519 DOT 00c09bb0 AT pop> <4 DOT 3 DOT 2 DOT 7 DOT 0 DOT 20001001212519 DOT 00c09bb0 AT pop> <20001002114023 DOT H13304 AT cygnus DOT com> <4 DOT 3 DOT 2 DOT 7 DOT 0 DOT 20001113000139 DOT 00c3ba60 AT pop DOT bresnanlink DOT net> <20001113115655 DOT J7424 AT redhat DOT com> <5 DOT 0 DOT 0 DOT 25 DOT 0 DOT 20001211202412 DOT 02930eb0 AT pop DOT bresnanlink DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 00:27 12/12/00 -0500, Christopher Faylor wrote: >On Mon, Dec 11, 2000 at 11:21:05PM -0600, Chris Abbey wrote: > >At 11:56 11/13/00 -0500, Christopher Faylor wrote: > >>Dunno. Probably, you're sending more than one CTRL-BREAK. It works > >>fine for me. > >> > >>cgf > > > >ok, I'd ask that you (and anyone else with a couple minutes) humor me > >If the "you" here is me, then I respectfully decline. it was, (the parenthetical was for anyone else) primarily because you claim this works for you, and I see no way in hell it can. I respectfully deduce then that you claim "wfm" without actually having ever tried it... where I work this is known as being "a wild eyed dreamer" or "full of it"... depending on if you're a engineer or a manager. :) >If you do find anything related to the way cygwin code operates, however, >feel free to post it here and I'll review it. that's the search I'm trying to do... I've read the docs, they don't tell me much, I've looked at the source, the header is completely uncommented... real freakin' usefull there. The actual C source makes claims as follows: If your signal handler terminates using <> (or implicit return), your program's execution continues at the point where it was when the signal was raised (whether by your program itself, or by an external event). However, clearly when I run under /bin/bash this isn't the case, but under /bin/sh it is. Heck, under /bin/bash the handler isn't even allowed to finish execution. I've read the thread between you and Mumit from the end of last year when you re implemented signals, and all the concerns with non cygwin binaries that load the dll, and the nasties that could occur therein... but I don't think that applies here (unless I miss read something) because the JVM *isn't* loading cygwin, it knows nothing of cygwin. The case here is cygwin's bash shell and handing signals to it's children. (that's my best guess so far anyway....) I'm really starting to get the feeling that integrating native winblows apps into cygwin isn't as smooth a process as some would like to believe. I'm seriously considering writing my own jni invocation java launcher that spins two threads, one to listen for the signal from cygwin the other to be attached to the JVM and raise the windows signal. But I just have a BAD feeling about that idea. :( the origin of that idea is this chunk of the strace output of bash running java... 15877875 20458425 [unknown (0xD4)] bash 92 _kill: kill (-92, 2) 420 20458845 [unknown (0xD4)] bash 92 kill_pgrp: pid 92, sig 2 2886 20461731 [unknown (0xD4)] bash 92 kill_pgrp: killing pid 92, pgrp 92, p->ctty 1073741824, myself->ctty 1073741824 709 20462440 [unknown (0xD4)] bash 92 kill_pgrp: killing pid 273, pgrp 92, p->ctty 1073741824, myself->ctty 1073741824 549 20462989 [unknown (0xD4)] bash 92 sig_send: pid 273, signal 2, its_me 0 271 20463260 [unknown (0xD4)] bash 92 getsem: pid 273, ppid 92, wait 10000, initializing 0 325 20463585 [unknown (0xD4)] bash 92 sig_send: Not waiting for sigcomplete. its_me 0 sig 2 237 20463822 [unknown (0xD4)] bash 92 sig_send: returning 0 from sending signal 2 213 20464035 [unknown (0xD4)] bash 92 kill_worker: 0 = kill_worker (273, 2) 446 20464481 [unknown (0xD4)] bash 92 sig_send: pid 92, signal 2, its_me 1 15874992 15912725 [sig] bash 273! wait_sig: awake 356 20464837 [unknown (0xD4)] bash 92 sig_send: Waiting for thiscomplete 0x8C 636 15913361 [sig] bash 273! wait_sig: processing signal 2 216 15913577 [sig] bash 273! wait_sig: Got signal 2 212 15913789 [sig] bash 273! sig_handle: signal 2 213 15914002 [sig] bash 273! sig_handle: signal 2, about to call do_exit 736 15914738 [sig] bash 273! signal_exit: about to call do_exit (10200) 399 15915137 [sig] bash 273! do_exit: do_exit (66048) 567 15915704 [sig] bash 273! void: 0x0 = signal (20, 0x1) 569 15916273 [sig] bash 273! void: 0x0 = signal (1, 0x1) 1269 15917542 [sig] bash 273! void: 0x0 = signal (2, 0x1) 467 15918009 [sig] bash 273! void: 0x0 = signal (3, 0x1) 3603 20468440 [sig] bash 92 wait_sig: awake 2299 20470739 [sig] bash 92 wait_sig: processing signal 2 1231 15919240 [sig] bash 273! fhandler_base::close: handle 0x6C 391 15919631 [sig] bash 273! proc_terminate: nchildren 0, nzombies 0 311 15919942 [sig] bash 273! proc_terminate: leaving 232 15920174 [sig] bash 273! sigproc_terminate: entering 344 15920518 [sig] bash 273! sigproc_terminate: done 92 is the bash process, 273 is the jvm. as I read that (and hopefully I'm wrong) process 273 isn't even bothering to tell the JVM, it's just exiting. compare that with the strace of sh running the jvm: 17087973 27178280 [unknown (0xD6)] sh 257 _kill: kill (-257, 2) 281 27178561 [unknown (0xD6)] sh 257 kill_pgrp: pid 257, sig 2 2458 27181019 [unknown (0xD6)] sh 257 kill_pgrp: killing pid 257, pgrp 257, p->ctty 1073741824, myself->ctty 1073741824 252 27181271 [unknown (0xD6)] sh 257 kill_pgrp: killing pid 67, pgrp 257, p->ctty 1073741824, myself->ctty 1073741824 290 27181561 [unknown (0xD6)] sh 257 sig_send: pid 67, signal 2, its_me 0 263 27181824 [unknown (0xD6)] sh 257 getsem: pid 67, ppid 257, wait 10000, initializing 0 373 27182197 [unknown (0xD6)] sh 257 sig_send: Not waiting for sigcomplete. its_me 0 sig 2 231 27182428 [unknown (0xD6)] sh 257 sig_send: returning 0 from sending signal 2 212 27182640 [unknown (0xD6)] sh 257 kill_worker: 0 = kill_worker (67, 2) 17084496 17115347 [sig] sh 67! wait_sig: awake 374 27183014 [unknown (0xD6)] sh 257 sig_send: pid 257, signal 2, its_me 1 509 27183523 [unknown (0xD6)] sh 257 sig_send: Waiting for thiscomplete 0x9C 557 17115904 [sig] sh 67! wait_sig: processing signal 2 600 17116504 [sig] sh 67! wait_sig: Got signal 2 224 17116728 [sig] sh 67! sig_handle: signal 2 216 17116944 [sig] sh 67! sig_handle: signal 2, about to call 0x40E56C 2012 17118956 [sig] sh 67! call_handler: armed signal_arrived 0x6C, res 1 223 17119179 [sig] sh 67! proc_subproc: args: 4, 1 218 17119397 [sig] sh 67! proc_subproc: clear waiting threads 227 17119624 [sig] sh 67! proc_subproc: finished clearing 217 17119841 [sig] sh 67! proc_subproc: returning 1 213 17120054 [sig] sh 67! call_handler: didn't suspend main thread, th 0x6108329C 217 17120271 [sig] sh 67! call_handler: returning 1 221 17120492 [sig] sh 67! sig_handle: returning 1 221 17120713 [sig] sh 67! wait_sig: looping 4794 27188317 [sig] sh 257 wait_sig: awake 243 27188560 [sig] sh 257 wait_sig: processing signal 2 896 27189456 [sig] sh 257 wait_sig: Got signal 2 242 27189698 [sig] sh 257 sig_handle: signal 2 239 27189937 [sig] sh 257 sig_handle: signal 2, about to call 0x40E56C 1109 27191046 [sig] sh 257 call_handler: armed signal_arrived 0xB4, res 1 234 27191280 [sig] sh 257 proc_subproc: args: 4, 1 229 27191509 [sig] sh 257 proc_subproc: clear waiting threads 237 27191746 [sig] sh 257 checkstate: nchildren 1, nzombies 0 231 27191977 [sig] sh 257 checkstate: checking alive children 230 27192207 [sig] sh 257 stopped_or_terminated: considering pid 67 229 27192436 [sig] sh 257 checkstate: returning -1 271 27192707 [sig] sh 257 proc_subproc: waiting thread found no children 241 27192948 [sig] sh 257 proc_subproc: finished clearing 229 27193177 [sig] sh 257 proc_subproc: returning 1 228 27193405 [sig] sh 257 call_handler: didn't suspend main thread, th 0x6108329C 231 27193636 [sig] sh 257 call_handler: returning 1 233 27193869 [sig] sh 257 sig_handle: returning 1 247 27194116 [unknown (0xD6)] sh 257 sig_send: returning 0 from sending signal 2 225 27194341 [unknown (0xD6)] sh 257 kill_worker: 0 = kill_worker (257, 2) 223 27194564 [unknown (0xD6)] sh 257 kill_pgrp: 0 = kill (257, 2) 935 27195499 [sig] sh 257 wait_sig: looping 30423 27225922 [main] sh 257 wait4: 0 = WaitForSingleObject (...) 341 27226263 [main] sh 257 wait4: intpid -1, status 0x241FA50, w->status -1, options 0, rc -1 232 27226495 [main] sh 257 wait4: *** errno = 4 225 27226720 [main] sh 257 reset_signal_arrived: reset signal_arrived 38882 17159595 [main] sh 67! spawn_guts: signal arrived 490 27227210 [main] sh 257 set_process_mask: old mask = 0, new mask = 2 258 27227468 [main] sh 257 set_process_mask: old mask = 2, new mask = 0 235 27227703 [main] sh 257 wait4: calling proc_subproc, pid -1, options 0 236 27227939 [main] sh 257 proc_subproc: args: 5, 1627959760 229 27228168 [main] sh 257 proc_subproc: wval->pid -1, wval->options 0 229 27228397 [main] sh 257 checkstate: nchildren 1, nzombies 0 229 27228626 [main] sh 257 checkstate: checking alive children 222 27228848 [main] sh 257 stopped_or_terminated: considering pid 67 221 27229069 [main] sh 257 checkstate: returning -1 216 27229285 [main] sh 257 proc_subproc: only found non-terminated children 219 27229504 [main] sh 257 proc_subproc: finished processing terminated/stopped child 227 27229731 [main] sh 257 proc_subproc: returning 1 where 67 is sh, 257 is jvm. To my unfamiliar eye that is a very different code path chosen by sh. This still only makes local on the console work, but that's an improvement I'll take over nothing. now the forces of openness have a powerful and unexpected new ally http://ibm.com/linux/ -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com