Linux-kernel mailing list archive 1997-48,: Re: adding extra signals for LinuxThreads (Re: Linux 2.1.69..)

# Re: adding extra signals for LinuxThreads (Re: Linux 2.1.69..)

=?ISO-8859-1?Q?Erkki_Sepp=E4l=E4?= (es60850@uta.fi)
Sat, 6 Dec 1997 12:48:36 +0200 (EET)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Pavel Machek: "process.c cleanup"
- Previous message: Andreas Jaeger: "Re: byteorder mess"
- In reply to: Peeter Joot: "adding extra signals for LinuxThreads (Re: Linux 2.1.69..)"

On Sat, 6 Dec 1997, Peeter Joot wrote:

> I think the problem here is that there aren't two free signals available on
> each platform. You would have to use a 64 bit integer so you can have a bit
> for each signal. This may not be too hard to add, but probably has a
> performance impact on all the 32 bit linuxes. But then again, maybe its not
> much.

Hmm, I didn't think of that. But if there really is no another way to
implement this, then this must be done sooner or later. Right?
I don't think that adding another integer would introduce a major
performance hit, but on the other hand, I don't know what I'm talking
about :).
Also I've heard that some level of posix introduces custom signals, how
are they going to be handled? I don't know anything more about this
matter..

> There may also be binary compatibility problems to solve too.

I guess that for ia32 platform there is no other way to 'blend' the code
than to create a new system call, which accepts a 64-bit bitmask. And
change libc too. Or maybe glibc2 already uses 64-bit masks, I don't know.
_____________________________________________________________________
/ __// /__ ____ __ http://www.inside.org/~flux/\ \
/ /_ / // // /\ \/ / \ /
/_/ /_/ \___/ /_/\_\@inside.org \/

- Next message: Pavel Machek: "process.c cleanup"
- Previous message: Andreas Jaeger: "Re: byteorder mess"
- In reply to: Peeter Joot: "adding extra signals for LinuxThreads (Re: Linux 2.1.69..)"