Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#62 gtmshr call-in library drops to GTM prompt on CTRL+C

open
nobody
None
5
2012-12-29
2005-02-04
Steve Zeck
No

If a user aborts a program that calls-in to GT.M, GT.M
can drop the user to the 'GTM> ' prompt. This is most
likely to occur when the program makes numerous calls
in a row, such as in a for() loop.

GT.M installs itself as a signal handler for SIGINT
during gtm_init() even when invoked only through the
gtmshr call-in library. If the program had previously
registered itself as a signal handler, this association
will have been lost after gtm_init().

Workaround: reinstall your own signal handler after
calling gtm_init() (subsequent calls to GT.M through
gtm_ci() do not seem to make it re-register itself).
If the program/script uses the shell defaults for
signal handling, it is necessary to create a handler
for at least SIGINT if dropping to GTM is not desired.

Workaround: instruct user to type 'halt' at GTM> prompt
if it is encountered.

It would be nice if GT.M would not install itself this
way during gtm_init() or would detect that it was
invoked by call-in and automatically halt when CTRL+C
is detected, rather than drop to GTM> prompt.

Discussion

  • Logged In: YES
    user_id=220075

    Hi Steve,
    As documented in the technical bulletin (TB5-027), this is one
    of the limitations of using signals with call-ins. We have an
    internal tracking number (C9D04-002256) to support a
    scheme allowing handlers from both sides, but that was
    pushed down in the priority list due to other higher priority
    items.

    Regarding your particular concern with SIGINT, it is the
    documented behavior to drop to GTM> prompt upon entering
    CTRL-C. This behavior can be controlled using the terminal's
    CENABLE device parameter. By default, CENABLE is enabled
    and causes the process to drop to the direct mode. If
    dropping to the prompt is your only concern, you can disable
    this behavior with "USE $P:(NOCENABLE)" in the called-in
    routine.

    As you pointed out, GT.M doesn't re-register the signals in
    gtm_ci() once done after gtm_init() based on the assumption
    that user doesn't change these in the interim. If it is
    necessary to create your own SIGINT handler, reinstalling it in
    between might work, but we wouldn't recommend this
    approach until C9D04-002256 is fixed.

    Let us know if you have any questions,
    Thanks
    -malli

     
  • Logged In: YES
    user_id=220075

    Hi Steve,
    As documented in the technical bulletin (TB5-027), this is one
    of the limitations of using signals with call-ins. We have an
    internal tracking number (C9D04-002256) to support a
    scheme allowing handlers from both sides, but that was
    pushed down in the priority list due to other higher priority
    items.

    Regarding your particular concern with SIGINT, it is the
    documented behavior to drop to GTM> prompt upon entering
    CTRL-C. This behavior can be controlled using the terminal's
    CENABLE device parameter. By default, CENABLE is enabled
    and causes the process to drop to the direct mode. If
    dropping to the prompt is your only concern, you can disable
    this behavior with "USE $P:(NOCENABLE)" in the called-in
    routine.

    As you pointed out, GT.M doesn't re-register the signals in
    gtm_ci() once done after gtm_init() based on the assumption
    that user doesn't change these in the interim. If it is
    necessary to create your own SIGINT handler, reinstalling it in
    between might work, but we wouldn't recommend this
    approach until C9D04-002256 is fixed.

    Let us know if you have any questions,
    Thanks
    -malli

     
  • Logged In: YES
    user_id=220075

    Hi Steve,
    As documented in the technical bulletin (TB5-027), this is one
    of the limitations of using signals with call-ins. We have an
    internal tracking number (C9D04-002256) to support a
    scheme allowing handlers from both sides, but that was
    pushed down in the priority list due to other higher priority
    items.

    Regarding your particular concern with SIGINT, it is the
    documented behavior to drop to GTM> prompt upon entering
    CTRL-C. This behavior can be controlled using the terminal's
    CENABLE device parameter. By default, CENABLE is enabled
    and causes the process to drop to the direct mode. If
    dropping to the prompt is your only concern, you can disable
    this behavior with "USE $P:(NOCENABLE)" in the called-in
    routine.

    As you pointed out, GT.M doesn't re-register the signals in
    gtm_ci() once done after gtm_init() based on the assumption
    that user doesn't change these in the interim. If it is
    necessary to create your own SIGINT handler, reinstalling it in
    between might work, but we wouldn't recommend this
    approach until C9D04-002256 is fixed.

    Let us know if you have any questions,
    Thanks
    -malli