View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000156 | ascend | general | public | 2005-12-07 20:32 | 2008-02-10 13:03 |
| Reporter | john | ||||
| Assigned To | john | ||||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | |||||
| Target Version | Fixed in Version | 0.9.6 | |||
| Summary | 0000156: SIGINT trap makes it difficult to debug hanging processes | ||||
| Description | If we take away the SIGINT trap in ASCEND it makes it easier to locate hanging processes using GDB. I will add compiler flags that allow this to be done. Are there any issues with removing the SIGINT trap for released versions? Most other linux programs that I use don't mess around with preventing ctrl-C interrupts. If run from the console they can easily be interrupted but if from from the GUI they need to be killed in other ways. Perhaps it's just the case the the signal handling is broken, and ctrl-C interrupt is supposed to work, actually? How about windows? | ||||
| Tags | No tags attached. | ||||
|
|
Reminder sent to: ben, jds Hi there Would be interested to have your comments on this. Cheers JP |
|
|
From Jerry: John; Doesn't matter much to me. My impression is that trapping ctrl-C signals will be even less important on Windows. I haven't really thought it through, though. My guess is that Ben will offer the most insightful comments about the merits of your question. Jerry |
|
|
From Ben: Ctrl-C in ascend interrupts the solver and otherwise is ignored. My recollection is that there's a way to turn interrupt handling on and off from tcl using one of the ascend extension functions, which precludes the need for a special build. re production builds, I suggest users continue to be able to interrupt the solver with ctrl-c by default. this also comes handy when the gui is non-responsive and you can send the process a signal with kill (on unix anyway). ben |
|
|
I think that ctrl-C should behave in the standard way and interrupt the application. An unresponsive GUI is a bug. |
|
|
In any case, I don't think the functionality should be turned off in ascSignal.[ch]. ascSignal just provides a signal management facility, not a compulsion to use it. This is an interface issue, and it doesn't seem that the base library should build differently depending on whether one plans to use SIGINT handling. If there are aspects of the ascSignal implementation that are problematic (e.g. firing SIGINT during the initialization), then it's better to provide a way to modify the behavior interactively than build the library differently for different scenarios. This could be parameters to Asc_SignalInit(), or new functions to set static flags controlling the behavior. Within the tcl/tk interface, I'm indifferent (at this point) to selective building versus an extension function. |
|
|
Ben added changeset 149. Ben, just wondering about how you see this working with non-TCL GUIs? Aren't the initial traps set in ascConfig or ascSignal or somewhere like that? Perhaps this stuff should be in the base/generic code? |
|
|
I see the handling of ctrl-c as being specific to a particular interface (e.g. tcltk vs pygtk vs buried in an extension to matlab or excel under windows). Therefore, the signal handling for sigint is entirely in the province of the tickle interface. Other interfaces are not (and should not) be required to support the documented behavior of the tickle interface wrt sigint. |
|
|
Deleted your note " fixed in version 154 [^] . slv_[un]trapint provides facilities to turn ctrl-c trapping on and off." -- changeset 154 related to another bug. |
|
|
This was resolved by turning off the signal-tests by default in the SCons build. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-12-07 20:32 | john | New Issue | |
| 2005-12-07 20:33 | john | Note Added: 0000077 | |
| 2005-12-15 04:48 | john | Note Added: 0000088 | |
| 2005-12-15 04:48 | john | Note Added: 0000089 | |
| 2005-12-15 04:49 | john | Note Added: 0000090 | |
| 2005-12-15 05:56 | jds | Note Added: 0000091 | |
| 2005-12-21 02:37 | john | Note Added: 0000123 | |
| 2005-12-21 02:40 | john | Status | new => assigned |
| 2005-12-21 02:40 | john | Assigned To | => ben |
| 2005-12-21 05:46 | ben | Note Added: 0000137 | |
| 2005-12-21 05:52 | john | Note Added: 0000140 | |
| 2006-01-24 04:10 | john | Relationship added | related to 0000122 |
| 2006-02-07 13:19 | john | Target release | => 1.0 |
| 2006-02-07 13:24 | john | Target release | 1.0 => 0.9.6 |
| 2006-05-10 02:32 | john | Assigned To | ben => john |
| 2006-05-10 02:34 | john | Status | assigned => resolved |
| 2006-05-10 02:34 | john | Resolution | open => fixed |
| 2006-05-10 02:34 | john | Note Added: 0000326 | |
| 2006-06-22 07:28 | john | Fixed in Version | => 0.9.6 |
| 2008-02-10 13:03 | john | Status | resolved => closed |
