Linux-Development-Sys Digest #87, Volume #8 Sat, 19 Aug 00 18:13:10 EDT
Contents:
Re: debugging/profiling multithreaded (pthread) applications on RedHat 6.x? (Nate
Eldredge)
Re: IRDA-Support on Sparc (Daniel Newby)
Re: self wake up sleep in ther kernel (Nic)
Re: debugging/profiling multithreaded (pthread) applications on RedHat 6.x? (Kaz
Kylheku)
Re: Can't use both USB printer and Promise Ultra66 at the same time (Tim Moore)
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Pcmcia-cs and Forms Library for Xwindows ("E-mu")
Merging keyboard input with serial console input? (Mike McDonald)
Unicode under Linux? (Linuxer)
Re: UID width (Daniel Robert Franklin)
Re: IRDA-Support on Sparc ("Jan Welti")
Re: Can't use both USB printer and Promise Ultra66 at the same time ("Jan Welti")
Re: Unicode under Linux? ("Jan Welti")
Re: all threads in a process share the same pid? (James Avery)
Lineo Embedix SDK ("David")
3com 3c509 driver (Phong Ho)
kernel problem for 128MB RAM (Nuclear)
Re: all threads in a process share the same pid? (Torkel Bj�rnson-Langen (3aa))
Re: all threads in a process share the same pid? (Xavier Leroy)
Re: Linux Driver Tools (Nix)
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Re: all threads in a process share the same pid? (Kaz Kylheku)
Re: all threads in a process share the same pid? (Kaz Kylheku)
How to implement a embedded linux? ("NTUST")
Linux server to hold thousands of tcp connections? (J R)
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Nate Eldredge <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: debugging/profiling multithreaded (pthread) applications on RedHat 6.x?
Date: 18 Aug 2000 16:34:09 -0700
[EMAIL PROTECTED] (Kaz Kylheku) writes:
> On Thu, 17 Aug 2000 19:19:08 GMT, Szabolcs Csetey <[EMAIL PROTECTED]> wrote:
> >> Also, what about tools for profiling multithreaded aps? We've found
> >Tau and
> >> are trying to use it. Is there anything else?
> >
> >AFAIK gprof doesn't support multithreaded apps profiling, but you can
> >workaround it if you call getitimer() in the main thread for ITIMER_PROF
> >then using that value in a call to setitimer() in every thread you
> >spawn. Other alternative is using the open source cprof by Corel [I
> >never had the chance to try it out yet]:
>
> Profiling in Linux is not based on the profiling alarm timer. It is
> based on a special profiling system call. You give it a buffer which
> represents a scaled histogram over an area of your virtual address
> space. The kernel then racks up counters within that histogram. When
> your process is interrupted by a clock tick, the kernel notes what
> address it was executing and maps it into that histogram and then
> bumps a counter. Or something like that!
This is wrong.
$ gcc -pg foo.c
$ strace ./a.out
[...]
rt_sigaction(SIGPROF, {0x400bbb70, ~[], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0
setitimer(ITIMER_PROF, {it_interval={0, 1}, it_value={0, 1}}, {it_interval={0, 0},
it_value={0, 0}}) = 0
--- SIGPROF (Profiling timer expired) ---
sigreturn() = ? (mask now [])
[...]
As you can see, it does indeed use the ITIMER_PROF timer. Kernel
2.2.17pre, glibc 2.1.3.
You are probably thinking of the old `profil' system call, which
according to its man page worked like you describe. However, my man
page implies that it hasn't been a syscall since Linux 0.99.11, and it
certainly isn't one now (entry.S shows where it returns -ENOSYS
instead).
--
Nate Eldredge
[EMAIL PROTECTED]
------------------------------
From: Daniel Newby <[EMAIL PROTECTED]>
Subject: Re: IRDA-Support on Sparc
Date: Fri, 18 Aug 2000 18:43:08 -0500
Paul Dwerryhouse wrote:
>
> Robert Resch <[EMAIL PROTECTED]> writes:
>
> >Why can't i select the IRDA-Support on my SparcStation2 and RedHat Linux
> >6.2 (Kernel 2.2.16) ?
>
> You shouldn't need IRDA support for that - since it's a serial device,
> it should be able to be accessed in the same way you'd access any other
> serial device - that is, via /dev/ttyS0, /dev/ttyS1, etc...
But accessing IrDA as a serial device is pretty worthless, like
talking to a raw Ethernet card. You need the higher protocol
layers.
IIRC, the IrDA stuff is still considered experimental. Try
turning on the "enable experimental stuff" choice when
configuring your kernel. (I'm assuming you are rebuilding
your kernel and the IrDA options don't show up.)
------------------------------
From: Nic <[EMAIL PROTECTED]>
Subject: Re: self wake up sleep in ther kernel
Date: Sat, 19 Aug 2000 11:55:57 +1200
Peter Huang wrote:
>
> Hi all
>
> I am looking for a sleep function that can wake up after it sleep for a
> period of time by the kernel. I'm not sure how to implement it with
> interruptible_sleep_on or sleep_on since both functions wait on a wait
> queue. I'm looking for a function that is similar to
>
> sleep(20ms)..
Take a look at schedule_timeout(timeout_in_jiffies), defined in
kernel/sched.c
Regards,
Nic.
--
My non-official mailbox: < sky at wibble dot net >
Internet Software & Security Consulting - http://www.bellamy.co.nz/
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: debugging/profiling multithreaded (pthread) applications on RedHat 6.x?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 18 Aug 2000 23:51:33 GMT
On 18 Aug 2000 16:34:09 -0700, Nate Eldredge <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Kaz Kylheku) writes:
>
>> Profiling in Linux is not based on the profiling alarm timer. It is
>> based on a special profiling system call. You give it a buffer which
>> represents a scaled histogram over an area of your virtual address
>> space. The kernel then racks up counters within that histogram. When
>> your process is interrupted by a clock tick, the kernel notes what
>> address it was executing and maps it into that histogram and then
>> bumps a counter. Or something like that!
>
>This is wrong.
Yow! Sorry about that and thanks for the correction.
------------------------------
From: Tim Moore <[EMAIL PROTECTED]>
Crossposted-To: alt.comp.periphs.mainboard.supermicro
Subject: Re: Can't use both USB printer and Promise Ultra66 at the same time
Date: Sat, 19 Aug 2000 00:07:33 GMT
> I've tried moving the Promise controller to a different slot. I've
> tried assigning it a different IRQ explicitly in the BIOS (that seems
> to have no effect). I don't know what else to try.
Turn of PnP in BIOS, then specifically assign IRQ's in BIOS.
--
| 650.390.9613 | [EMAIL PROTECTED]
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
From: [EMAIL PROTECTED]
Date: Sat, 19 Aug 2000 00:15:54 GMT
[EMAIL PROTECTED] writes:
> > It's quite irritating.
> On the other hand, having your software compile and run on every *nix
> variant except Linux is more irritating.
The solution is, of course, to run Linux on all computers.
--
Eric McCoy ([EMAIL PROTECTED])
"felon, n.: A person of greater enterprise than discretion, who in
embracing an opportunity has formed an unfortunate attachment."
------------------------------
From: "E-mu" <[EMAIL PROTECTED]>
Subject: Pcmcia-cs and Forms Library for Xwindows
Date: 19 Aug 2000 01:52:09 GMT
Where can Forms Library for X windows? After compliling and installing the
latest version of pcmcia-cs, it siad to also install the forms library.
------------------------------
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Mike McDonald)
Subject: Merging keyboard input with serial console input?
Date: Sat, 19 Aug 2000 03:55:57 GMT
I'm working on a driver for a PCI based PS2 keyboard. We currently don't
have a graphics driver so we're using a serial console. Inorder to show the
keyboard driver works, I'm display the scancodes on the LEDs. But this isn't
a very convincing demo. Is there anyway to get the keyboard's input merged
into the serial console's input stream, just as if I had typed them on the
serial keyboard?
Mike McDonald
[EMAIL PROTECTED]
------------------------------
From: Linuxer <[EMAIL PROTECTED]>
Subject: Unicode under Linux?
Date: Sat, 19 Aug 2000 15:33:47 +0800
Does linux kernel support unicode? I can't access multi-languages under
Linux, make me very headache. Any suggestions to me? thanks~~~
------------------------------
Subject: Re: UID width
From: [EMAIL PROTECTED] (Daniel Robert Franklin)
Date: 19 Aug 2000 16:17:30 +1000
Kevin Kaichuan He <[EMAIL PROTECTED]> writes:
> Hi, I faced a problem when trying to mount Solaris NFS
>export to linux. My UID in Solaris is larger than 65535, but
>it looks like linux's uid width is 16bit , so that it's impossible
>for me to set up correct UID to mount the Solaris filesystem.
> Is there a way to get around this problem? Thank you!
>Kevin
I think 2.3/2.4 has 32-bit UID support.
- Daniel
--
******************************************************************************
* Daniel Franklin - Postgraduate student in Electrical Engineering
* University of Wollongong, NSW, Australia * [EMAIL PROTECTED]
******************************************************************************
------------------------------
From: "Jan Welti" <[EMAIL PROTECTED]>
Subject: Re: IRDA-Support on Sparc
Date: Sat, 19 Aug 2000 11:44:17 +0300
It's actually called Prompt for incomplete code/drivers. (It's in the first
section of the menuconfig or xconfig).
--
The Rules Have Changed...Get Paid to Surf the Web!
http://www.alladvantage.com/go.asp?refid=IRU461
"Daniel Newby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Dwerryhouse wrote:
> >
> > Robert Resch <[EMAIL PROTECTED]> writes:
> >
> > >Why can't i select the IRDA-Support on my SparcStation2 and RedHat
Linux
> > >6.2 (Kernel 2.2.16) ?
> >
> > You shouldn't need IRDA support for that - since it's a serial device,
> > it should be able to be accessed in the same way you'd access any other
> > serial device - that is, via /dev/ttyS0, /dev/ttyS1, etc...
>
> But accessing IrDA as a serial device is pretty worthless, like
> talking to a raw Ethernet card. You need the higher protocol
> layers.
>
> IIRC, the IrDA stuff is still considered experimental. Try
> turning on the "enable experimental stuff" choice when
> configuring your kernel. (I'm assuming you are rebuilding
> your kernel and the IrDA options don't show up.)
------------------------------
From: "Jan Welti" <[EMAIL PROTECTED]>
Crossposted-To: alt.comp.periphs.mainboard.supermicro
Subject: Re: Can't use both USB printer and Promise Ultra66 at the same time
Date: Sat, 19 Aug 2000 11:46:28 +0300
Why don't you use your printer in the parallel port? Using USB won't have
any major speed advantage.
--
The Rules Have Changed...Get Paid to Surf the Web!
http://www.alladvantage.com/go.asp?refid=IRU461
"Tim Moore" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > I've tried moving the Promise controller to a different slot. I've
> > tried assigning it a different IRQ explicitly in the BIOS (that seems
> > to have no effect). I don't know what else to try.
>
> Turn of PnP in BIOS, then specifically assign IRQ's in BIOS.
> --
> | 650.390.9613 | [EMAIL PROTECTED]
------------------------------
From: "Jan Welti" <[EMAIL PROTECTED]>
Subject: Re: Unicode under Linux?
Date: Sat, 19 Aug 2000 11:51:47 +0300
That option is available in the kernel configuration. Run make config, make
menuconfig, or make xconfig in /usr/src/linux, if /usr/src/linux doesn't
exist check if there is a directory like linux-x.y.zz or
kernel-source-x.y.zz in /usr/src, if it exists run ln -s linux-x.y.zz linux,
if it doesn't exist install the sources from your linux installation cd.
Check ou the Kernel-HOWTO for more information.
--
The Rules Have Changed...Get Paid to Surf the Web!
http://www.alladvantage.com/go.asp?refid=IRU461
"Linuxer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Does linux kernel support unicode? I can't access multi-languages under
> Linux, make me very headache. Any suggestions to me? thanks~~~
>
------------------------------
From: James Avery <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: Sat, 19 Aug 2000 14:25:32 +0200
On Sat, 19 Aug 2000 [EMAIL PROTECTED] wrote:
> > > It's quite irritating.
>
> > On the other hand, having your software compile and run on every *nix
> > variant except Linux is more irritating.
>
> The solution is, of course, to run Linux on all computers.
Or on none.
--
Med venlig hilsen,
James Avery <[EMAIL PROTECTED]>
------------------------------
From: "David" <[EMAIL PROTECTED]>
Subject: Lineo Embedix SDK
Date: Sat, 19 Aug 2000 09:35:01 -0400
Has anyone here used the Lineo Embedix SDK? They sent me some
hype in the mail, and I was wondering if it is any good.
Thanks,
David
------------------------------
From: Phong Ho <[EMAIL PROTECTED]>
Subject: 3com 3c509 driver
Date: Sat, 19 Aug 2000 15:05:13 GMT
I examine the file 3c509.c in /drivers/net of the kernel. I do not
see the
'register_netdev()' statement. My understanding is that, a network
driver must
register with the kernel using 'register_netdev()' .
Can anyone let me know why the statement 'register_netdev' is not in the
file
3c509.c?
------------------------------
From: Nuclear <[EMAIL PROTECTED]>
Subject: kernel problem for 128MB RAM
Date: Sat, 19 Aug 2000 16:25:13 GMT
Hi there,
I'm using RedHat 6.2 (kernel 2.2.14-12).
But when i went onto upgrade my RAM to 128MB SDRAM my system
drastically slowed down. When I checked the system information thru'
the system monitor the memory status shown was only 32MB out of 128MB.
The system seemed to have been using only 32MB out of 128MB.
Pls. provide solution if available.
Can mail me at [EMAIL PROTECTED] or [EMAIL PROTECTED]
Thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Torkel Bj�rnson-Langen (3aa))
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: 19 Aug 2000 20:04:34 +0200
Xavier Leroy <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Linus Torvalds) writes:
>
> > >The standard states that all threads should share the same pid, and
> > >different thread ids.
> > Easily fixed:
> > [Cache PID of initial thread, override getpid()]
> > If the pthreads library doesn't do this already, then it should.
>
> I considered doing this early in the LinuxThreads development, and decided
> not to for the reasons given by other posters: problems with wait()
> and signals would still be there, perhaps made even more obscure
> by this "solution" (e.g. getppid() in a child process would not return the
> same PID as getpid() in its parent...).
>
> The only solution, in my opinion, is to fix the kernel so that the CLONE_PID
> option to clone() works. That would fix all remaining non-conformance
> issues for LinuxThreads.
If thats all, why don't someone fix it?
Sincerely,
Torkel
------------------------------
From: [EMAIL PROTECTED] (Xavier Leroy)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: 19 Aug 2000 22:00:30 +0200
[EMAIL PROTECTED] (Torkel Bj�rnson-Langen (3aa)) writes:
> > The only solution, in my opinion, is to fix the kernel so that the
> > CLONE_PID option to clone() works. That would fix all remaining
> > non-conformance issues for LinuxThreads.
>
> If thats all, why don't someone fix it?
Well, if you feel like fixing it yourself, everyone will be grateful...
I can see several reasons why the CLONE_PID option to clone() is still
broken 4 years after this system call was introduced:
1- It's hard fix. The assumption that processes have unique PIDs
permeates the kernel sources. Some significant work is needed
to support both PIDs and TIDs (thread IDs). Someone (forgot the name)
tried to do it a couple of years ago, but I don't think he went very far.
Also, signal delivery becomes even more tricky than it is today, due
to the wonderfully intricate semantics the POSIX people chose.
2- Apparently, none of the major kernel developers feel that this is a
serious issue. Which is why I was thrilled to see Linus enter the
discussion :-)
- Xavier Leroy
--
Valid e-mail address (without the underscores): [EMAIL PROTECTED]
This is a protection against junk mail. Apologies for the inconvenience.
Home page: http://pauillac.inria.fr/~xleroy/
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Linux Driver Tools
Date: 19 Aug 2000 22:12:51 +0100
Josef Moellers <[EMAIL PROTECTED]> writes:
> human generated code to
> handle driver internal data structures and machine generated code to
> handle the interface between driver and OS proper. Much like lex and
> yacc generate compilers: stinging together the human generated code.
Yes, good thought.
Of course, such indirection layers will slow the driver down...
--
`OS's and GUI's come and go, only Emacs has lasting power.' --- Per Abrahamsen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Sat, 19 Aug 2000 21:25:03 GMT
In comp.os.linux.development.apps Torkel Bj�rnson-Langen (3aa) <[EMAIL PROTECTED]>
wrote:
>> The only solution, in my opinion, is to fix the kernel so that the CLONE_PID
>> option to clone() works. That would fix all remaining non-conformance
>> issues for LinuxThreads.
> If thats all, why don't someone fix it?
Basically, because none of the core kernel developers believe that it
should work, apparantly. There's no incentive to fix it if the patch
won't be accepted. There's also no incentive to maintain the patch
outside the kernel, since then you'd basically be maintaining the
FreeBSD kernel.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Sat, 19 Aug 2000 21:34:01 GMT
In comp.os.linux.development.apps Xavier Leroy <[EMAIL PROTECTED]>
wrote:
> 1- It's hard fix. The assumption that processes have unique PIDs
> permeates the kernel sources. Some significant work is needed
> to support both PIDs and TIDs (thread IDs). Someone (forgot the name)
> tried to do it a couple of years ago, but I don't think he went very far.
> Also, signal delivery becomes even more tricky than it is today, due
> to the wonderfully intricate semantics the POSIX people chose.
The last I saw, there were about four patches that cleaned up most of
the big issues. The real problem is the portions other than
clone(). From what I've read on the kernel list, getting a change into
other portions of the kernel would probably prove impossible.
If there was anything remotely resembling consensus on an acceptable
way to do it, I suspect someone would fix it.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Aug 2000 21:33:02 GMT
On 19 Aug 2000 22:00:30 +0200, Xavier Leroy
<[EMAIL PROTECTED]> wrote:
>2- Apparently, none of the major kernel developers feel that this is a
>serious issue. Which is why I was thrilled to see Linus enter the
>discussion :-)
POSIX is broken in many areas anyway. For example, consider that the threads of
a POSIX process share the same current and root directory. (In Linux, this is
optionally achieved by CLONE_FS, which is currently hard-coded in
pthread_create).
It means, effectively, that threads cannot use chdir() (and chroot() as well),
except at the start of the program to set a global working directory. There is
no interface in POSIX to even put a lock on the current working directory so
that it can be relied on to be stable over a few system calls.
Also, in the POSIX model, one cannot have threads running under separate user
ID's, so that a multithreaded server could authenticate a user and then perform
file accesses using that user's credentials.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Aug 2000 21:47:10 GMT
On Sat, 19 Aug 2000 21:34:01 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.apps Xavier Leroy <[EMAIL PROTECTED]>
>wrote:
>
>> 1- It's hard fix. The assumption that processes have unique PIDs
>> permeates the kernel sources. Some significant work is needed
>> to support both PIDs and TIDs (thread IDs). Someone (forgot the name)
>> tried to do it a couple of years ago, but I don't think he went very far.
>> Also, signal delivery becomes even more tricky than it is today, due
>> to the wonderfully intricate semantics the POSIX people chose.
>
>The last I saw, there were about four patches that cleaned up most of
>the big issues. The real problem is the portions other than
>clone(). From what I've read on the kernel list, getting a change into
>other portions of the kernel would probably prove impossible.
>
>If there was anything remotely resembling consensus on an acceptable
>way to do it, I suspect someone would fix it.
The way I look at it, if someone can afford to use a few trivial noncompliances
as an excuse not to port something to Linux, then screw them.
The existing interface allows for a fighting chance to make useful MT software
that works on Linux and elsewhere, if that is necessary. One just has to pay
attention to the little things, like differences in fcntl F_SETLK locks, signal
handling and such.
Porting threaded programs among the other platforms is not that easy either.
Getting some Solaris program to work on, say, HP-UX might prove to as difficult
as getting it to work under LinuxThreads.
The existing implementations are buggy. For example, it recently came to light
in comp.programming.threads that the Solaris open() function screws up under
thread cancellation. In Linux, it's a direct system call, so it is safe. Some
application that cancels threads that are blocked in open() will currently work
better on Linux than Solaris.
So what else is new? Writing code for multiple UNIXes has traditionally been an
exercise in #ifdef. :) That is why so much freeware uses little test programs to
determine what works and what doesn't.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: "NTUST" <[EMAIL PROTECTED]>
Crossposted-To: comp.realtime,comp.unix.programmer,tw.bbs.comp.linux
Subject: How to implement a embedded linux?
Date: Sun, 20 Aug 2000 06:00:05 +0800
hello everbody
I have got a project about enbedded Linux recently.
It's a thin router which is based on Embedded Linux.
I confused to how to do that.
Because I don't have any experience to embed Linux.
So...I wanna get some help or suggestion.
Therefore , I list some objectives.
Objectives:
1.Based on the evaluation board of VIA-6509 with IDE interface,
build thin router software components.
2.porting from 80x86 platform to ARM-7 platform.
3.porting routing protocols(RIP,OSPF) to embedded Linux.
4.porting NAT(network address translator) to embedded.
5.protocol software debugging
As a result,I hope someone can resolve my problem.
thanks a lot ^.^
by daniel
------------------------------
From: J R <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.protocols.tcp-ip
Subject: Linux server to hold thousands of tcp connections?
Date: Sat, 19 Aug 2000 16:03:18 -0600
I am building an IM server for LINUX that will accept connections and
hold them open for asyn communication (very much the same as AOL). I
need some ideas about how to go about this.
Should I use BSD sockets or go to a lower layer? What are the max # of
BSD sockets that could probably be held open at the same time on LINUX?
How do I go to a lower layer if I wanted too? Resources? Any ideas
would be great?
joe r
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Sat, 19 Aug 2000 22:03:56 GMT
In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> It means, effectively, that threads cannot use chdir() (and chroot()
> as well), except at the start of the program to set a global working
> directory. There is no interface in POSIX to even put a lock on the
> current working directory so that it can be relied on to be stable
> over a few system calls.
> Also, in the POSIX model, one cannot have threads running under
> separate user ID's, so that a multithreaded server could
> authenticate a user and then perform file accesses using that user's
> credentials.
These are both actually the same "problem" which is that the standard
defines _threads_ and not _processes_. Either of these is better
solved through creating children processes than new threads.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
