This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [long] Re: signals?


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 <<return>> (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....)

<sigh> 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@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]