Linux-Development-Sys Digest #89, Volume #8 Sun, 20 Aug 00 08:13:09 EDT
Contents:
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? ([EMAIL PROTECTED])
Re: PCI Initialization of Cards buggy or I miss something? (Tim Roberts)
Re: doing mmap() twice on the same fd ([EMAIL PROTECTED])
Re: Linux server to hold thousands of tcp connections? ([EMAIL PROTECTED])
Re: doing mmap() twice on the same fd ([EMAIL PROTECTED])
Re: Circumventing TIME_WAIT...howto? ("Robert Colbert")
Re: Circumventing TIME_WAIT...howto? ("Robert Colbert")
Re: Can't use both USB printer and Promise Ultra66 at the same time ("Jan Welti")
Problems with file modes (Grahame Jordan)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Sun, 20 Aug 2000 02:31:18 GMT
In comp.os.linux.development.apps [EMAIL PROTECTED] wrote:
> Or, perhaps, a new API which does the threading the way it should be
> done. The fact that you suggest a "new" API for the "current" system
> suggests you're deliberately trying to cast Kaz's suggestion in the
> worst possible light.
It shouldn't suggest anything of the sort. What I meant, and if this
wasn't clear, is that the pthread_* family of functions should give
you posix threads by default. Having them do double duty is fine, as
long as the people wanting LinuxThreads are the ones that have to
change the behavior through some non-standard function. (Which may be
as simple as #define _LINUX_THREADS when compiling)
As far as "threading the way it should be done" goes, I'll admit that
I'm biased towards thinking the standard is the way it should be
done. There are, however, two different arguments that come up with
threads.
First is the "argument from standards" which is actually a collection
of points that really amount to "standards are good things." They
include the political reality that non-standard products tend to do
poorly in the marketplace, that standards requirements are a part of
some markets, that standards make portable code possible, etc.
There's also the "technical argument" which would claim that one or
the other is "better" based on comparative merits. This, right now, is
what seems to be the stake through the heart of pthreads.
On the political front, we basically have the core kernel developers
Vs the posix committe. Both are arguably skilled enough to develop a
working threaded model. However, everything else being equal, I'd go
for the Posix implemntation unless the competeing proposal was cleary
superior.
Which brings us to the technical front. I maintain that threads should
be contained within the same process, while other people maintain that
they should be sperate processes sharing some pages. As near as I can
tell, that causes numerous problems (including the ten I posted
previously) with the one advantage that it's easier to implement.
The two other technical arguments, that it would slow down the kernel,
and that it's possible to do in userspace have yet to be proven, in my
opinion. I would be interesting in seeing someone prove me wrong by
producing:
1. A compelling benchmark that proves single-threaded applications run
significantly faster on Linux compared to comperable FreeBSD or
Solaris boxes.
2. A user-space solution that allows one process to wait on the
children of another process.
--
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: Sun, 20 Aug 2000 02:27:27 GMT
On Sun, 20 Aug 2000 00:58:12 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>
>> No, because clone() cannot be mixed with pthread programming. Clone
>> threads cannot safely call into glibc (only into a subset of
>> it). Only threads created with pthread_create are adorned with the
>> proper dressing which allows them to have the full library at their
>> disposal.
>
>That may be, but you didn't ask for pthreads. What you want is a
>non-standard threading system that maintains a different working
>directory for every thread.
But not at the cost of not being able to do anything else!
>On top of that, you said you were willing
>to sacrifice portability in order to have it.
But not sacrifice being able to call printf! ;) Only portability in the
sense that the non-standard threading attribute is used.
--
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]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Sun, 20 Aug 2000 03:01:00 GMT
In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> But not sacrifice being able to call printf! ;) Only portability in the
> sense that the non-standard threading attribute is used.
Fair enough, but see my post on making it a compile-time option. ;)
I still feel, however, that the _correct_ way to approach the problem
is via some variant of fork and ipc. Forks are, as a general rule,
fast enough now that you're not looking at tremendous overhead except
in special cases.
What's really frustrating about the entire topic is that however often
pthread proponents admit that there may be cases where the Linux
approach is better, there is next to noone who will admit that the
Posix model has merits too. In fact, the standard tends to be written
off as a "brain damaged piece of crap" without justifying that point
of view at all.
That being said, I'm perfectly happy to have _both_ kinds of
threads. The problem is that the big advantage of the current system
seems to be its simplicity. adding Posix threads to the kernel would,
in my opinion, remove any use for the current ones.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: PCI Initialization of Cards buggy or I miss something?
Date: Sat, 19 Aug 2000 22:43:54 -0700
Nikos Kalogridis <[EMAIL PROTECTED]> wrote:
>Hi I am currently working on a driver for a pci device. I am using the
>2.4-test6 and RH6.2.
>I have an ASUS CUV4X with a Celeron 633MHz on it. The BIOS is the Award
>Medallion 6.0.
>I encountered the following problems when the PNP OS option in the BIOS
>is enabled.
Linux is not a PnP OS. Neither is Windows NT, nor Windows 2000. The only
operating systems for which the PnP OS option should be enabled are Windows
95 and Windows 98. That is the ENTIRE list.
>Does anyone has any clues on what it could be the problem here. (Apart
>from telling me to disable the option in the BIOS which by the way if I
>do the card works just fine). From my point of view is should be a bug
>in the PCI code.
I don't understand why you want to force this to work with an incorrect
BIOS setting. If the option were renamed "Are you running Windows 9X?"
(which it might as well be), would you still want Linux to work with the
option set to "yes"?
With "PnP OS" turned on, the BIOS can leave the PCI resources in a
self-conflicted state. It believes that an operating system will
eventually come along and fix things up. That isn't happening here.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: doing mmap() twice on the same fd
Date: Sun, 20 Aug 2000 08:59:24 GMT
On 18 Aug 00 08:40:21 GMT Mattias Engdeg�rd <[EMAIL PROTECTED]> wrote:
|> Is it possible to do mmap() twice on the same fd, but as a different
|> number produced from dup(), where one or both is passed to a different
|> process, when the fd was opened to /dev/zero, and get both of those
|> processes to share memory?
|
| No. mmap() on /dev/zero is synonymous to mmap() with MAP_ANON and always
| gives you a fresh block of anonymous memory (copy-on-write).
| Recent Linux development kernels allow you to mmap anonymous memory
| as shareable, but you can't send a mapping to an unrelated process that
| way. (I agree that it would be a neat trick.)
Clearly 2 separate opens of /dev/zero would be separate memory. But do
the "rules" say this must be so even if the same fd, even if a dupped fd,
is used twice?
| You have to map a temporary file. This isn't as bad as it sounds:
| The asynchronous write policy of Linux filesystems makes it almost as
| efficient as anonymous memory, and if you immediately unlink the file
| after creating it, it won't survive your processes either.
If I create the file in ramdisk, will mapping that occupy ram once or
twice? This system will have no writeable filesystems except ramdisk
since it will be running from CDROM.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.networking,comp.protocols.tcp-ip
Subject: Re: Linux server to hold thousands of tcp connections?
Date: Sun, 20 Aug 2000 09:05:43 GMT
In comp.os.linux.development.system J R <[EMAIL PROTECTED]> wrote:
| 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?
If you can implement a TCP stack in your userland code, you could use
the ethertap facility to really get down low. I'm planning to use it
for a special network monitoring tool.
Otherwise I would suggest fanning the connections out over multiple
forked child processes that can (de-)multiplex the streams to the
parent or to each other as needed.
The limit is the number of file descriptors available, usually 1024 or
maybe 4096, but this can be changed though things could begin to get
slow at that point since I believe they are not searched using methods
that are good at that scale. OTOH, that many open could be slow on the
whole system even if spread over a number of processes. I'm just not
sure and hopefully a kernel guru will reply.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: doing mmap() twice on the same fd
Date: Sun, 20 Aug 2000 09:12:41 GMT
On 18 Aug 00 08:40:21 GMT Mattias Engdeg�rd <[EMAIL PROTECTED]> wrote:
|> Is it possible to do mmap() twice on the same fd, but as a different
|> number produced from dup(), where one or both is passed to a different
|> process, when the fd was opened to /dev/zero, and get both of those
|> processes to share memory?
|
| No. mmap() on /dev/zero is synonymous to mmap() with MAP_ANON and always
| gives you a fresh block of anonymous memory (copy-on-write).
| Recent Linux development kernels allow you to mmap anonymous memory
| as shareable, but you can't send a mapping to an unrelated process that
| way. (I agree that it would be a neat trick.)
Something else I just recalled. A couple years ago I needed to share a
circular buffer between a parent and child process, and the steps in the
buffer were not submultiples of the buffer size, hence at wraparound,
there was a bit of complication doing read() and write(). Someone gave
a suggestion to mmap the space twice so there was a buffer twice as large,
but the first half was a replica of the second half. I thought it was an
interesting idea but I never actually did it that way. It was for
anonymous sharing between the processes, and not on a file. Was that a
broken idea? I cannot recall the technique suggested.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: "Robert Colbert" <[EMAIL PROTECTED]>
Subject: Re: Circumventing TIME_WAIT...howto?
Date: Sun, 20 Aug 2000 02:37:11 -0700
> So what exactly are you complaining about? If it's that you can't bind
> to the port, you need to set SO_REUSEADDR.
Rick:
It's not an issue of bind or the reuse of a local address or port. The
server machine(s) only bind once and continue to run indefinitely until the
test is stopped. I don't have a problem with bind. The client machines are
not able to successfully call socket() because the OS's socket table is
filled with sockets lingering for over two minutes in the TIME_WAIT state.
I've received another reply here suggesting the passive close. I'm going to
try that first chance I get on Monday.
Thanks for your replies! :-)
Thanks,
-Rob
"Rick Ellis" <[EMAIL PROTECTED]> wrote in message
news:8njlho$bnc$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> Robert Colbert <[EMAIL PROTECTED]> wrote:
>
> >So, given that our full-duplex, switched, routed dual-VLAN internal,
> >isolated 12 Gigabit network of 96 PCs and a few controller PCs does not
drop
> >packets and no packet takes longer than about 2ms to reach its
destination,
> >yep, I'm very positive that I don't need a two-minute TIME_WAIT clog in
this
> >environment. And, UDP doesn't do "session" traffic (or even use the right
> >protocol for what we're testing).
>
> So what exactly are you complaining about? If it's that you can't bind
> to the port, you need to set SO_REUSEADDR.
>
> --
> http://www.fnet.net/~ellis/photo/linux.html
>
------------------------------
From: "Robert Colbert" <[EMAIL PROTECTED]>
Subject: Re: Circumventing TIME_WAIT...howto?
Date: Sun, 20 Aug 2000 02:55:21 -0700
Kaz:
First, thank you for the reply! I do have a question though about:
> One way is to have the clients disconnect gracefully from the server.
> The TIME_WAIT occurs on the side which initiates the closure.
Am I making a mistake by calling close on both sides? Or, is it that I am
not calling close on the server side when I detect that the client has gone
away? Here's what my session looks like in C (not the full TCP traffic)...
[server side]
bind()
listen()
accept()
while( recv() )
{
send()
}
return; // end
[client side]
connect()
send()
recv();
close();
return; // end
Should the server side be modifed to look more like:
[server]
bind()
listen()
accept()
while( recv() )
{
send();
}
close();
return; // end
Understanding that I have written the most psuedo of pseudo-code up there,
is my mistake not calling close on both sides? And, should I use SO_LINGER
so that both sides are forced to wait for all close() traffic to happen
(FIN/ACK, ACK, FIN/ACK, ACK)?
Thanks again in advance,
-Rob Colbert ([EMAIL PROTECTED])
"Kaz Kylheku" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 17 Aug 2000 02:43:22 -0700, Robert Colbert <[EMAIL PROTECTED]>
wrote:
> >In essence, is there any "proper" way to get around this TIME_WAIT state
> >in a socket without a kernel hack?
>
> One way is to have the clients disconnect gracefully from the server.
> The TIME_WAIT occurs on the side which initiates the closure.
>
> You find that if you are testing a client server application, the
> TIME_WAIT problem occurs when you abruptly terminate the server without
> disconnecting the clients first.
>
> Take a look at the TCP state transition diagram. Note that if you leage
> the ESTABLISHED state by receiving a FIN (the other end is closing), the
> connection goes straight to the state CLOSE_WAIT, in which it waits
> for the application to complete the close. Then it sends a FIN and waits
> for the last ACK in the LAST_ACK state. This scenario is called passive
> close, and does not involve the TIME_WAIT state.
>
> See if you can design your application to take advantage of passive close
> in order to avoid the TIME_WAIT.
>
> The SO_REUSEADDR option can also be used to circumvent TIME_WAIT in some
TCP
> implementations. This allows a process to bind to the local port that is
in the
> TIME_WAIT state.
>
> --
> 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: "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: Sun, 20 Aug 2000 14:33:38 +0300
Does your UDMA66 controller work without the driver?
--
The Rules Have Changed...Get Paid to Surf the Web!
http://www.alladvantage.com/go.asp?refid=IRU461
"Jonathan Kamens" <[EMAIL PROTECTED]> wrote in message
news:8nnbmv$8f8$[EMAIL PROTECTED]...
> In article <8nlhe1$j7c$[EMAIL PROTECTED]>,
> "Jan Welti" <[EMAIL PROTECTED]> writes:
> >Why don't you use your printer in the parallel port? Using USB won't have
> >any major speed advantage.
>
> Because I've already got another printer plugged into the parallel
> port.
>
> >"Tim Moore" <[EMAIL PROTECTED]> wrote in message
> >> Turn of PnP in BIOS, then specifically assign IRQ's in BIOS.
>
> I already tried explicitly assigning IRQs. My BIOS lets me do that
> even when PnP isn't enabled. It didn't help (in fact, the Promise
> card seems to ignore the PnP assignment I give it). I know that the
> IRQ assignments in the BIOS are supposed to work even when PnP isn't
> enabled because some of my other cards do in fact pay attention to the
> assignments.
>
> Are you sure that the PnP setting will make a difference?
------------------------------
From: Grahame Jordan <[EMAIL PROTECTED]>
Subject: Problems with file modes
Date: Sun, 20 Aug 2000 21:49:44 +1000
Hi!
Running RH5.2 Kernel 2.2.7 there is one behaviour with file permissions.
Running RH6.2 Kernel 2.2.16 there is other behaviour.
RH5.2
A directory /home/users is 750 and owned by root.admin
admin lives in /home/users/admin modes 700
>From root we can "su - admin" no problems
RH6.2
Same scenario as above I su - admin and cannot find the home directory.
"su: warning: cannot change directory to /home/users/admin: Permission
denied"
After I am logged in as admin I can "cd" and I am there.
To solve this problem I chmod o+x "/home/users" and it is OK.
Hence there is differrent behaviour between these two versions. Either
in the kernel or in some utility. (Maybe PAM cannot see ~admin)?
This has change behaviour.
Any one know what has happened?
Thanks
Grahame Jordan
--
=======================
- I see, I forget; -
- I read I know; - (Understanding Year 1&2 Maths)
- I do, I understand. - (Alan Horsfield)
=======================
------------------------------
** 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
******************************
