Linux-Development-Sys Digest #941, Volume #7 Thu, 8 Jun 00 19:13:16 EDT
Contents:
Net device driver -- mixing protocol levels? (Tom Roberts)
HELP: SIMPLE IRQ Routine Crashes (Tod Daniels)
Re: books on linux programming (Philip)
Re: finding filename from file descriptor (Mario Klebsch)
Re: finding filename from file descriptor (Mario Klebsch)
Errors while compiling 2.2.15 kernel (SooperGrover)
Re: Winmodems )Re: Need ideas for university funded project for linux) (Jan Knutar)
Re: Net device driver -- mixing protocol levels? (Aki M Laukkanen)
Re: syslogd no longer work , why ? (Christian Plattner)
Errors: Too Many Open Files in System (Mike Robbins)
Re: Linux TCP/IP stack internal (Sebastien Dessimoz)
Re: Errors: Too Many Open Files in System (Art Haas)
Re: Winmodems )Re: Need ideas for university funded project for linux) (Erik Max
Francis)
Perl script in C wrapper won't suid (Edward Block)
Re: Binary file formats. ("A derelict Engineer")
Re: Perl script in C wrapper won't suid (Paul Kimoto)
Re: HELP: SIMPLE IRQ Routine Crashes (Andrey Vlasov)
Re: exit()/pthreads bug on Linux PPC (Peter Burka)
Re: Linux TCP/IP stack internal (Stefaan A Eeckels)
Re: exit()/pthreads bug on Linux PPC (Kaz Kylheku)
----------------------------------------------------------------------------
From: Tom Roberts <[EMAIL PROTECTED]>
Subject: Net device driver -- mixing protocol levels?
Date: Thu, 08 Jun 2000 12:25:07 -0500
I now have a pair of working network device drivers between my host
and my board. Except that the board cannot ping any network host
other than its own host -- in other words the host is not acting
properly as a network gateway for the board. I think it is configured
correctly (various routes look OK).
I think the problem is in what looks to me like a deliberate mixing
of protocol layers in Linux's definition of a network device driver.
When the driver receives a packet, it must fill an sk_buff structure
with the packet data, its length, the protocol id, mac.raw, and
pkt_type. I understand and agree with all but this last.
Well, why should the higher layers care about mac.raw?
AFAICT all that is needed is that mac.raw point somewhere
between skb->head and skb->data, so the higher layers are
only checking it for sanity, and not looking at its value.
pkt_type is to be set to one of: PACKET_HOST, PACKET_BROADCAST,
PACKET_MULTICAST, or PACKET_OTHERHOST. It seems to me that this is
a layer 3 issue, and not a link-layer issue. The only way I know
of to determine this is to examine the IP destination of the
IP packet (which is the payload of the link layer implemented by
the driver). Why does my driver need to understand the layout of
an IP datagram? Why does it need to care about its own payload?
So I think the reason my host does not act as a gateway for my board
is that in the driver I did not examine the received IP packet, and
simply set pkt_type to PACKET_HOST.
Tom Roberts [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Tod Daniels)
Subject: HELP: SIMPLE IRQ Routine Crashes
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Date: 8 Jun 2000 13:42:02 -0400
I'm trying to develop a device driver for an Emulex Xp (and DCP486p) series
synchronous serial card for Linux v2.2.6. I hope to see the code make it
on to an interesting project like the Linux Router Project, but right now
it has some problems.
My biggest problem is that my routine for servicing interrupts generates a
kernel fault. The routine is simple and only tries to write a message to
KERN_INFO. See below for information from various sources...
The sources are based on information from Rubini's _Writing Linux Device
Drivers_ and from various sources on the web including Becker's _skeleton.c_
and the Linux Documentation Project's _Device Drivers_.
Thanks for any help!!!
Tod Daniels
Here is the output from the KERN_DEBUG message:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
current->tss.cr3 = 034a1000, %cr3 = 034a1000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c48280e2>]
EFLAGS: 00010286
eax: ffffffff ebx: 00000000 ecx: 00000002 edx: c3e1c000
esi: 00000000 edi: c4829047 ebp: 00000000 esp: c34a3f74
ds: 0018 es: 0018 ss: 0018
Process bash (pid: 2724, process nr: 26, stackpage=c34a3000)
Stack: c4827fd0 00000000 ffffff0a c0123d9c 00000000 c3fcfa70 c34a2000 c30a9bc0
00000006 c012422e c30a9bc0 400cc000 00000006 c30a9bd4 c34a2000 00000006
400cc000 bffff4fc 00000000 c0108a94 00000001 400cc000 00000006 00000006
Call Trace: [<c4827fd0>] [<c0123d9c>] [<c012422e>] [<c0108a94>]
Code: ac ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 2c
The code I wrote to service the interrupt is as follows:
static void dcpInterruptService(int irq, void *dev_id, struct pt_regs *regs)
{
printk(KERN_INFO "Servicing Interrupt %02d.\n", irq);
}
And the lines I used to request the interrupt is:
if (request_irq(Card->Irq, &dcpInterruptService, 0,
"Emulex DCP/Xp", &devSerial[0]))
// NOTE, has also been tried with NULL in argument #5!!!
printk("failed.\n");
else
printk("installed.\n");
NOTE: the actual requested irq is 11. The output from /proc/interrupts shows
that the routine is registered properly, but something this simple fails --
and I do not understand why!!!
[/proc/interrupts]
CPU0
0: 15431843 XT-PIC timer
1: 8 XT-PIC keyboard
2: 0 XT-PIC cascade
5: 225877 XT-PIC eth0
8: 1 XT-PIC rtc
11: 0 XT-PIC Emulex DCP/Xp
13: 1 XT-PIC fpu
14: 70387 XT-PIC ide0
NMI: 0
------------------------------
From: Philip <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: books on linux programming
Date: Thu, 08 Jun 2000 17:55:36 GMT
Reference manual :
Beginning Linux Programming . Richard Stones and Neil Matthew
Learning programming (in C) :
Any book about C .. ABC : A Book about C
--
Philip van Hoof aka freax _/_/_/
irc: freax @ undernet.org _/_/ _/ _/_/ _/_/_/ _/_/ _/ _/
http://users.pandora.be/skatan _/_/ _/ _/ _/ _/ _/ _/ _/
mailto:[EMAIL PROTECTED] _/_/_/_/ _/ _/ _/_/ _/_/_/_/ _/_/
Hey, it will happen. They'll _/_/ _/ _/ _/ _/ _/ _/
go where the money is(Linus)_/_/ _/ _/_/_/ _/ _/ _/ _/
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: finding filename from file descriptor
Date: Thu, 8 Jun 2000 19:11:13 +0200
John Reiser <[EMAIL PROTECTED]> writes:
>The knowledge of one or more pathnames associated with an open file
>descriptor can be useful for documentation, audit or debugging.
>"/tmp is accumulating zero-length files. Is some application crashing
>before unlink?" "Here's a 100MB file that is growing by 100 bytes per
>second. Which process is responsible?"
In this case, you already have the file. You know Dev&Ino and you can
easily search each process list of open files of it.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: finding filename from file descriptor
Date: Thu, 8 Jun 2000 19:14:04 +0200
Josef Moellers <[EMAIL PROTECTED]> writes:
>Mario Klebsch wrote:
>> Sending rights over a connected UNIX domain socket? Connected sockets
>> are STREAM sockets. This did not work on Linux, the last time I tried
>> it. When I used UNIX domain DGRAM socket instead, it worked.
>Why so overly complicated?
>Just open /proc/<oldprocess>/fd/<filedescriptor>!
It would require enough permission to open the file. When using
FD-passing the receivin process can access files, even if permissions
are not suficcient to open them.
You also have to keep the files open at least until the client
application can grab its own handle. When you use fd-passing, you can
close it just after you have send it away.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SooperGrover)
Subject: Errors while compiling 2.2.15 kernel
Date: Thu, 08 Jun 2000 18:34:15 GMT
I'm not sure where to send this information, so I post it here,
trusting that it will receive the correct follow-up.
When I compile the 2.2.15 kernel I get a long list of errors. Non of
them seem to be fatal enough to abort the compile and I can still use
the kernels produced. However, the messages suggest the source isn't
entirely clean and this bothers me. I've collected the errors below:
--->8---
during 'make depend':
newport.c:11: asm/gfx.h: No such file or directory
newport.c:12: asm/ng1.h: No such file or directory
newport.c:14: asm/newport.h: No such file or directory
config.c:455: #error "HiSax: No cards configured"
adb.c:28: asm/prom.h: No such file or directory
adb.c:29: asm/adb.h: No such file or directory
adb.c:30: asm/cuda.h: No such file or directory
adb.c:31: asm/pmu.h: No such file or directory
adb.c:33: asm/hydra.h: No such file or directory
during 'make zImage':
mtrr.c:308: warning: `main_lock' defined but not used
apm.c:647: warning: `apm_enable_power_management' defined but not used
bios32.c: In function `pci_fixup_rcc':
bios32.c:1058: warning: unused variable `bus'
bios32.c: In function `pci_fixup_compaq':
bios32.c:1073: warning: unused variable `bus'
init.c:387: warning: section attribute ignored for uninitialized
variable `i386_endbase'
Root device is (3, 4)
Boot sector 512 bytes.
Setup is 3536 bytes.
System is 394 kB
during 'make modules':
/usr/src/linux/include/linux/blk.h:427: warning: `do_sd' defined but
not used
/usr/src/linux/include/linux/blk.h:451: warning: `do_sd_request'
declared `static' but never defined
scsi.h:641: warning: `end_scsi_request' defined but not used
If you need additional information just let me know...
--
Maurice Hendrix
...Hard rijden is geen kunst... Ben jij je rechtervoet de baas?
------------------------------
From: [EMAIL PROTECTED] (Jan Knutar)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Winmodems )Re: Need ideas for university funded project for linux)
Date: Thu, 08 Jun 2000 11:55:56 GMT
On 2 Jun 2000 14:59:14 GMT, [EMAIL PROTECTED] (Donal K. Fellows) wrote:
>In article <3934f551.1073003@news>, Jan Knutar <[EMAIL PROTECTED]> wrote:
>> My 33.6 modem often passes 128Kb/s when sucking usenet posts.
>
>Your USENET newsgroup set must be more compressible than mine; I
>rarely get more than 90Kb/s through a faster connection (and yes, it
>is going full tilt...)
>
>(Perhaps I read groups with more new signal in them and less repeated
>noise. :^)
Hmm.. I did mean to write 128 Kilo bits per second and not bytes per
second, can't remember what 'b' stands for bit and what b stands for
byte...
--
JK <[EMAIL PROTECTED]>
Any attempt to stretch fuel is guaranteed to increase headwind.
------------------------------
From: [EMAIL PROTECTED] (Aki M Laukkanen)
Subject: Re: Net device driver -- mixing protocol levels?
Date: 8 Jun 2000 20:13:12 GMT
In article <[EMAIL PROTECTED]>, Tom Roberts wrote:
>with the packet data, its length, the protocol id, mac.raw, and
>pkt_type. I understand and agree with all but this last.
> Well, why should the higher layers care about mac.raw?
Think tcpdump.
>pkt_type is to be set to one of: PACKET_HOST, PACKET_BROADCAST,
>PACKET_MULTICAST, or PACKET_OTHERHOST. It seems to me that this is
>a layer 3 issue, and not a link-layer issue. The only way I know
Completely fine to leave it as default. Links which support
native broadcasting/multicasting or devices that can be set to
promiscuous mode can give a hint to upper layers this way.
--
D.
------------------------------
From: Christian Plattner <[EMAIL PROTECTED]>
Subject: Re: syslogd no longer work , why ?
Date: Fri, 09 Jun 2000 00:06:30 +0200
> the log file in my linux system are no longer recorded but it rotated. i
depends on how you "rotated". I guess syslog cannot write to the
file-descriptors
anymore. just stop/start syslog to reopen (in this case create) the
logfiles.
(in SuSe do something like "/sbin/init.d/syslog stop" then
"/sbin/init.d/syslog start")
- Christian
--
- Christian Plattner
=================================
e-mail address: [EMAIL PROTECTED]
Ignore the dashes, these are just a junk mail protection.
------------------------------
From: Mike Robbins <[EMAIL PROTECTED]>
Subject: Errors: Too Many Open Files in System
Date: Thu, 08 Jun 2000 20:30:10 GMT
I'm pretty knowledgeable about Linux, but have never really played around
with Kernel development before. My web hosting company often has problems
which, under telnet, result in messages like shared libraries not loading,
etc. This is caused by too many files being opened at once; this I know
for a fact. Is there a #define in the Kernel source somewhere which can
raise this number of files? Is there a downside to doing this?
Thanks,
Mike Robbins
www.gamerack.com
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
Date: Thu, 08 Jun 2000 13:30:23 -0700
From: Sebastien Dessimoz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: Linux TCP/IP stack internal
Thanks Stefaan for your help.
However, I still do not have the answer to my question.
It is maybe because I didn't give enough information for understanding my
graph.
1. The different curves represent different socket buffer sizes.
2. X-axis is the block size [bytes]. Be careful it is a logarithmic scale.
3. Y-axis: the throughput [Mb/s]
To measure the throughput, Netpipe makes N write() system calls, each one of
the specified block size.
Thus my question stays the same: how come that the maximum throughput
(450Mb/s) is for a block size of 48 kB?
The maximum throughput can indeed be explained by my memory bandwidth.
But where does the 48 kB come from? At the beginning, I was thinking that it
was related to the socket buffer size, but it isn't as you can see on the
graph...
Thanks for your help,
Sebastien
Stefaan A Eeckels wrote:
> In article <[EMAIL PROTECTED]>,
> Sebastien Dessimoz <[EMAIL PROTECTED]> writes:
> > This is a multi-part message in MIME format.
> >
> > I was just measuring the "internal" throughput of the Linux TCP/IP stack
> > (kernel 2.2.12) with NetPipe 2.3.
> > It means that I run a client and a server on the same host (localhost)
> > and that I measure the throughput between them. I did that for different
> > block sizes (the data size for a write() system call), socket buffer
> > sizes and MTU. An example of graph is given in attachment.
> >
> > A very interesting result is that the maximum throughput is at about 48
> > kB whatever the MTU or the socket buffer size is.
> Since when is 450Mb/s (450 mega-bits per second) 48 kilo-bytes?
> Your graph _does_ show a maximum throughput of 450Mb/s with packets
> of 32kB and 64kB, and by my arithmetic, that's about 45 mega-bytes
> per second.
>
> > I think that this magic number has something to do with the Linux
> > internal, as it doesn't depend on the MTU or socket buffer.
> > Maybe is it related to a cache size or the MMU? Does somebody know why?
> > Please can you help me?
> Write a little program that reads from memory, writes to memory,
> and gives an idea of the memory to memory transfer speed. Compare
> that with your throughput using sockets, then wonder if a lot of
> process switching might not explain the apparent performance
> of the TCP/IP stack.
>
> --
> Stefaan
> --
> --PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)--
> Ninety-Ninety Rule of Project Schedules:
> The first ninety percent of the task takes ninety percent of
> the time, and the last ten percent takes the other ninety percent.
------------------------------
From: Art Haas <[EMAIL PROTECTED]>
Subject: Re: Errors: Too Many Open Files in System
Date: 08 Jun 2000 15:49:39 -0500
Mike Robbins <[EMAIL PROTECTED]> writes:
> I'm pretty knowledgeable about Linux, but have never really played around
> with Kernel development before. My web hosting company often has problems
> which, under telnet, result in messages like shared libraries not loading,
> etc. This is caused by too many files being opened at once; this I know
> for a fact. Is there a #define in the Kernel source somewhere which can
> raise this number of files? Is there a downside to doing this?
>
You'll want to look at the things in `/proc/sys/fs' - particularly
`file-max'. You can dynamically adjust the kernel parameters regarding
file handles ...
$ cd /proc/sys/fs
$ cat some_big_number > file-max
Read `/usr/src/linux/Documentation/sysctl/fs.txt' for more info.
--
###############################
# Art Haas
# (713) 689-2417
###############################
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Winmodems )Re: Need ideas for university funded project for linux)
Date: Thu, 08 Jun 2000 14:01:39 -0700
Jan Knutar wrote:
> Hmm.. I did mean to write 128 Kilo bits per second and not bytes per
> second, can't remember what 'b' stands for bit and what b stands for
> byte...
Lowercase b stands for bit, uppercase B stands for byte. In SI-like
standards, B stands for byte, but there is no abbreviation for bit, so
yu'd just write 128 kbit/s, or, if the k was meant to mean 1024 and not
100, 128 Kibit/s.
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ To love without criticism is to be betrayed.
\__/ Djuna Barnes
Polly Wanna Cracka? / http://www.pollywannacracka.com/
The Internet resource for interracial relationships.
------------------------------
From: Edward Block <[EMAIL PROTECTED]>
Subject: Perl script in C wrapper won't suid
Date: Thu, 08 Jun 2000 15:02:31 -0600
This should be simple...
I want to run a perl5 script with suid set. I followed the directions
and advise given at Perl's FAQ:
http://www.perl.com/pub/doc/FAQs/cgi/wwwsf5.html#Q49
This doens't seem to work. The Perl library
/usr/lib/perl5/5.00503/File/Copy.pm complains about insecure
dependancies while runing setuid. I thought if I write a C wrapper like
#include <unistd.h>
void main () {
execl("/usr/local/bin/perl","foo.pl","/local/web/cgi-bin/foo.pl",NULL);
}
it would work...
Is there something I've missed?
Any help would be greatly appreciated
Thanks
Ed Block
------------------------------
From: "A derelict Engineer" <[EMAIL PROTECTED]>
Subject: Re: Binary file formats.
Date: Thu, 8 Jun 2000 15:36:18 -0700
I recommend:
http://www.wotsit.org/default.asp
I didn't specifically check for the a.out format, but this site documents
THOUSANDS of file formats; I've rarely found one that they were missing...
<[EMAIL PROTECTED]> wrote in message
news:8hidpn$qth$[EMAIL PROTECTED]...
> Greeting:
>
> I need the detail documents about the format
> of a.outobject file, a.out executable file, ELF
> files. Does anyone know the location of them?
>
> Thanks a lot.
>
>
> Allen
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: Perl script in C wrapper won't suid
Date: 8 Jun 2000 18:45:10 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Edward Block wrote:
This is off-topic for c.o.l.d.system, but what the heck.
> I want to run a perl5 script with suid set. I followed the directions
> and advise given at Perl's FAQ:
>
> http://www.perl.com/pub/doc/FAQs/cgi/wwwsf5.html#Q49
(That's not a _perl_ FAQ: the perl FAQ proper is quite long and can
probably be found by running "perldoc perlfaq" or "man perlfaq" or
"... perlfaq1", "...perlfaq2", etc.)
> This doesn't seem to work. The Perl library
> /usr/lib/perl5/5.00503/File/Copy.pm complains about insecure
> dependancies while runing setuid. I thought if I write a C wrapper
[simple code deleted]
> it would work...
That message would seem to indicate that the kernel (i.e., system) part of
the setuid business is working correctly: the message is coming from perl
and probably would not arise if the system weren't trying to invoke perl
with setuid set.
You get error messages like that (and it's usually better to quote them
_exactly_) from perl's "taint-checking" mechanism, which is there to
prevent you from making horrible security mistakes. You can read about it
in the perlsec(1) man page, or in the Camel Book.
(There is a useful, and possibly helpful, catalog of perl error messages in
the perldiag(1) man page.)
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: Andrey Vlasov <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: HELP: SIMPLE IRQ Routine Crashes
Date: Thu, 08 Jun 2000 15:48:26 -0700
Hi,
are you sure that syntax of line correct
printk(KERN_INFO "Servicing Interrupt %02d.\n", irq);
as I never seen something like that. Normaly in C it looks
printk(KERN_INFO, "Servicing Interrupt %02d.\n", irq);
^^^
or
printk("KERN_INFO Servicing Interrupt %02d.\n", irq);
^^^
Check syntax. I do not have any experience with
developing of drivers but it looks wrong from
point of C syntax which I had to use. It seems to
me that it should be like in case #1.
Andrey
------------------------------
From: Peter Burka <[EMAIL PROTECTED]>
Subject: Re: exit()/pthreads bug on Linux PPC
Date: Thu, 08 Jun 2000 22:58:20 GMT
Peter Burka wrote:
>
>
> It just occurred to me, though, that I do install an atexit hook.
> I'll try taking that out and see what happens.
>
I tried taking out the atexit hook and the pthread_once initializer.
This made no difference.
/peter
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: comp.os.linux.networking
Subject: Re: Linux TCP/IP stack internal
Date: Fri, 9 Jun 2000 01:00:33 +0200
In article <[EMAIL PROTECTED]>,
Sebastien Dessimoz <[EMAIL PROTECTED]> writes:
> Thanks Stefaan for your help.
>
> However, I still do not have the answer to my question.
Oops -- I misunderstood your original question. You clearly said
"at 48kbps", and I interpreted it like you thought that was the
maximum throughput. My bad.
> It is maybe because I didn't give enough information for understanding my
> graph.
>
> 1. The different curves represent different socket buffer sizes.
> 2. X-axis is the block size [bytes]. Be careful it is a logarithmic scale.
> 3. Y-axis: the throughput [Mb/s]
>
> To measure the throughput, Netpipe makes N write() system calls, each one of
> the specified block size.
>
> Thus my question stays the same: how come that the maximum throughput
> (450Mb/s) is for a block size of 48 kB?
> The maximum throughput can indeed be explained by my memory bandwidth.
> But where does the 48 kB come from? At the beginning, I was thinking that it
> was related to the socket buffer size, but it isn't as you can see on the
> graph...
Have you tried it with, say, 63K or only with 32K, 48K and 64K?
You'll see the throughput increase until about 63.5K, and then
fall off because the write has to be split over 2 packets.
The total length of an IP packet is stored in a 16-bit field,
giving a maximum size of 64K bytes for a packet, so the payload
will be a bit less than 64K.
Take care,
--
Stefaan
--
--PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)--
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: exit()/pthreads bug on Linux PPC
Reply-To: [EMAIL PROTECTED]
Date: Thu, 08 Jun 2000 23:06:11 GMT
On Thu, 08 Jun 2000 22:58:20 GMT, Peter Burka <[EMAIL PROTECTED]> wrote:
>Peter Burka wrote:
>>
>>
>> It just occurred to me, though, that I do install an atexit hook.
>> I'll try taking that out and see what happens.
>>
>
>I tried taking out the atexit hook and the pthread_once initializer.
>This made no difference.
Say, does the code play with signal masks anywhere? In particular, is the
sigprocmask function being used by any chance rather that pthread_sigmask? The
reason I'm asking is because at exit time, threads are terminated using the
same signal that is used as the basis of cancellation. This signal is
unblocked by all threads at all times, and pthread_sigmask has safeguards to
ensure that you cannot block that signal.
--
#exclude <windows.h>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
