svn commit: r285404 - head/sys/compat/cloudabi

[Ed Schouten]

Hi Kostik,

2015-07-11 22:56 GMT+02:00 Konstantin Belousov <kostikbel at gmail.com>:
>> Bucket 2: The system call could also just fail and return an error
>> (MSG_NOSIGPIPE).
> SIGPIPE exists to ensure that naive programs do something reasonable
> when their stdout suddenly goes away. Or, transposing the PoV, it allows
> to write useful and well-behaving programs while ignoring complications.
> If all programs must be aware of the special error code from write which
> indicates that nobody listens to the output anymore, it would cause
> unneeded code copy/pasted all over the src.

Exactly. I think that for programs that are built around pipelines,
where a series of processes have stdin/stdout attached, having
something like SIGPIPE makes sense. So far the focus

>> > If your ABI does not provide any way to install a signal handler, then
>> > you probably should be already fully set up, due to execsigs() performed
>> > on each exec(2).
>>
>> Exactly. The kern_sigaction() is just needed to make sure that if the
>> process is started up with certain signals ignored, that raise() still
>> causes the process to terminate. If there is no way you can influence
>> the signal handling, you'd probably want that functions like abort()
>> can always throw SIGABRT.
>
> No. The point of my first message is that kern_sigaction + list is the
> unmaintanable approach. Take a look at the execsigs() again. You should
> implement a loop over the ps_sigignore sigset similar to the loop over
> ps_sigcatch in execsigs. Then you do not need to maintain a signal list.
>
> Later, when you design an interface to reflect traps to the userspace
> in your ABI, you would have some table to translate trap identifiers
> (or whatever) to FreeBSD signals.  Right now you do not need them.

Ah, okay. Now I think I understand what you're hinting at. So your
proposal is to let cloudabi_sys_proc_raise() only call into
sys_kill(), nothing else. We then reset all signals to their default
behavior at some point during process startup.

Let me address this by the time I'm sending out the CloudABI sysentvec
for review, as that would be the place where I'd need to do that. I'll
remove the call to kern_sigaction() in the meantime. Does that sound
all right?

-- 
Ed Schouten <ed at nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands
KvK/VAT number: 62051717