variable(s) for signal numbers?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

variable(s) for signal numbers?

John W. Eaton-6
I just implemented a kill function for Octave so you can send signals
to other processes (for example, those you started asynchronously with
system, or a fork/exec).  Now I see that it would be useful to have a
way to access signals by name instead of number, so that you could
write

  kill (pid, SIGHUP);

instead of

  kill (pid, 1);

for example.  The problem with using names like SIGHUP, SIGINT,
etc. is that it adds a lot of built-in variables.  Perhaps it would be
better to have a structure, say __siglist__ (or something, suggestions
for a better name are welcome), that has members like HUP, INT, etc,
so you would write

  kill (pid, __siglist__.HUP);

Then we only add one name to the list of built-in variables instead of
many.

OTOH, to someone used to programming Unixy systems, this doesn't look
as familiar as using SIGHUP.

Comments?

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: variable(s) for signal numbers?

Andy Adler
I think that the second form would be fine.
Everyone who wants to use kill should be
doing "help kill" first anyway.

Additionally, you then would have the semantics to
pull some 'perl'ish tricks and define virtual signals.

I'm refering to $SIG{__WARN__} and $SIG{__DIE__},
which refer to code doing the corresponding things.

Andy


On Fri, 10 Jan 2003, John W. Eaton wrote:

> I just implemented a kill function for Octave so you can send signals
> to other processes (for example, those you started asynchronously with
> system, or a fork/exec).  Now I see that it would be useful to have a
> way to access signals by name instead of number, so that you could
> write
>
>   kill (pid, SIGHUP);
>
> instead of
>
>   kill (pid, 1);
>
> for example.  The problem with using names like SIGHUP, SIGINT,
> etc. is that it adds a lot of built-in variables.  Perhaps it would be
> better to have a structure, say __siglist__ (or something, suggestions
> for a better name are welcome), that has members like HUP, INT, etc,
> so you would write
>
>   kill (pid, __siglist__.HUP);
>
> Then we only add one name to the list of built-in variables instead of
> many.
>
> OTOH, to someone used to programming Unixy systems, this doesn't look
> as familiar as using SIGHUP.
>
> Comments?
>
> Thanks,
>
> jwe
>
>


Reply | Threaded
Open this post in threaded view
|

Re: variable(s) for signal numbers?

John W. Eaton-6
On 10-Jan-2003, Andy Adler <[hidden email]> wrote:

| I think that the second form would be fine.
| Everyone who wants to use kill should be
| doing "help kill" first anyway.

OK, I decided to use a struct called SIG with fields like INT, HUP,
etc.  So you write SIG.HUP, which is not too bad, I suppose, and also
gives you an easy way to get the values for all of the available
signals.

| Additionally, you then would have the semantics to
| pull some 'perl'ish tricks and define virtual signals.
|
| I'm refering to $SIG{__WARN__} and $SIG{__DIE__},
| which refer to code doing the corresponding things.

I'm not sure how this would work.

I am also interested in being able to set up handlers for signals
inside Octave code, so you could have your own handlers.  But this
will require a bit more work, I think.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: variable(s) for signal numbers?

Andy Adler
On Fri, 10 Jan 2003, John W. Eaton wrote:

> On 10-Jan-2003, Andy Adler <[hidden email]> wrote:
> | Additionally, you then would have the semantics to
> | pull some 'perl'ish tricks and define virtual signals.
> |
> | I'm refering to $SIG{__WARN__} and $SIG{__DIE__},
> | which refer to code doing the corresponding things.
>
> I'm not sure how this would work.
>
> I am also interested in being able to set up handlers for signals
> inside Octave code, so you could have your own handlers.  But this
> will require a bit more work, I think.

Yes, this would clearly require more work. I was mentioning
the the syntax could be extended in this way.

Now that I look at it, Much of the general consensus within the Perl
community seems to be "$SIG{__DIE__} considered harmful".
People are encouraged to use Perl exception handling instead.

Perl uses die both to end script execution (as in error), or
like "throw" for exceptions. I just checked Matlab's version
of try/catch, and it is very similar to Perl, in that
error is used to throw an (untyped) exception, which is then
caught with "catch".

FWIW, I'm not a big fan of this kind of semantic overloading
(of "die" or "error").

I'll now retract my suggestion, as I no longer think its a
particularly good idea.

Andy