> Ok, but fd 0 cant be a valid socket since its the stdin
Wrong. fd 0 can be a valid socket. Read the man page to 'accept' again.
Remember again that zero is a non-negative integer.
> I posted that on this mailing list coz I thought that this might
> be a scaling
> problem since it
> What version of Linux are you using ? What I see is the following:
I'm using 2.4.1-pre10, glibc 2.1.3.
> Thread1
> Thread1
> Thread1
> Thread1
> Thread1
> Thread2
> Thread2
> Thread2
> Thread2
> Thread2
That's
The program you attached worked perfectly for me. You need to
'fflush(stdout);' after each 'printf'. You didn't expect perfect alternation
did you? That's totally unrealistic. You cannot use the scheduler as a
synchronization mechanism.
--
Thread1
Thread1
Thread2
Thread1
Thread1
> What does it typically mean when accept returns 0
> and that the perror outputs "Interupted system call"??
Since 'accept' returning zero is not an error, the results of 'perror' are
meaningless. Please read the manual page for 'accept' and notice that it
says, "The call returns -1 on
What does it typically mean when accept returns 0
and that the perror outputs "Interupted system call"??
Since 'accept' returning zero is not an error, the results of 'perror' are
meaningless. Please read the manual page for 'accept' and notice that it
says, "The call returns -1 on
The program you attached worked perfectly for me. You need to
'fflush(stdout);' after each 'printf'. You didn't expect perfect alternation
did you? That's totally unrealistic. You cannot use the scheduler as a
synchronization mechanism.
--
Thread1
Thread1
Thread2
Thread1
Thread1
Ok, but fd 0 cant be a valid socket since its the stdin
Wrong. fd 0 can be a valid socket. Read the man page to 'accept' again.
Remember again that zero is a non-negative integer.
I posted that on this mailing list coz I thought that this might
be a scaling
problem since it happens
What version of Linux are you using ? What I see is the following:
I'm using 2.4.1-pre10, glibc 2.1.3.
Thread1
Thread1
Thread1
Thread1
Thread1
Thread2
Thread2
Thread2
Thread2
Thread2
That's totally
> On Sat, Jan 27, 2001 at 02:18:31PM -0800, David Schwartz wrote:
> > > Firewalling should be implemented on the hosts, perhaps with
> > > centralized
> > > policy management. In such a situation, there would be no
> > > reason to filter
> > >
> Firewalling should be implemented on the hosts, perhaps with centralized
> policy management. In such a situation, there would be no reason to filter
> on funny IP options.
That's madness. If you have to implement your firewalling on every host,
what do you do when someone wants to
Firewalling should be implemented on the hosts, perhaps with centralized
policy management. In such a situation, there would be no reason to filter
on funny IP options.
That's madness. If you have to implement your firewalling on every host,
what do you do when someone wants to run a
On Sat, Jan 27, 2001 at 02:18:31PM -0800, David Schwartz wrote:
Firewalling should be implemented on the hosts, perhaps with
centralized
policy management. In such a situation, there would be no
reason to filter
on funny IP options.
That's madness. If you have to implement
> mprotect the page(s) you are interested in so you can't write to them
> and catch SEGV -- when someone attempts to write you can pull apart
> the stack frame mark the page(s) RO and continue.
>
> if you are really stuck i think i have example code to do this
> somewhere for ia32 (stack frame
mprotect the page(s) you are interested in so you can't write to them
and catch SEGV -- when someone attempts to write you can pull apart
the stack frame mark the page(s) RO and continue.
if you are really stuck i think i have example code to do this
somewhere for ia32 (stack frame is
> I'm _not_ seeing the point for a high-performance link to have a generic
> packet buffer.
>
> Linus
Well suppose your RAID controller can take over control of disks
distributed throughout your I/O subsystem. If you assume the bandwidth of
the I/O subsystem is not the
> ...and I still don't understand why the identical program, but using one
> socket instead of 2 sockets, IS CPU bound, and gets on the order of
> 10K/sec. on the same HW. Diffs to produce 10K/sec. 1 socket version from
> my previous sample follow...
It's really this simple -- this
I'm _not_ seeing the point for a high-performance link to have a generic
packet buffer.
Linus
Well suppose your RAID controller can take over control of disks
distributed throughout your I/O subsystem. If you assume the bandwidth of
the I/O subsystem is not the
...and I still don't understand why the identical program, but using one
socket instead of 2 sockets, IS CPU bound, and gets on the order of
10K/sec. on the same HW. Diffs to produce 10K/sec. 1 socket version from
my previous sample follow...
It's really this simple -- this isn't
and
> > > data becomes available, it doesn't return until the next clock tick.
>
> David Schwartz wrote:
> > This program doesn't demonstrate anything except that
> > Linux's sleep time is
> > granular. This shouldn't be news to anyone. If you don't
> If select() is waiting for data to become available on a
> TCP socket FD, and
> data becomes available, it doesn't return until the next clock tick.
If your application has scheduling requirements, you need to communicate
them to the scheduler.
> #include
> #include
>
If select() is waiting for data to become available on a
TCP socket FD, and
data becomes available, it doesn't return until the next clock tick.
If your application has scheduling requirements, you need to communicate
them to the scheduler.
#include sys/time.h
#include
return until the next clock tick.
David Schwartz wrote:
This program doesn't demonstrate anything except that
Linux's sleep time is
granular. This shouldn't be news to anyone. If you don't force
a reschedule,
everything works the way it's supposed to:
The sample program you included
> I have been trying to increase the scalabilty of an email server that has
> been ported to Linux. It was originally written for Netware, and there we
> are able to provide over 30,000 connections at any given time. On Linux
> however select stops working after the first 1024 connections. I
I have been trying to increase the scalabilty of an email server that has
been ported to Linux. It was originally written for Netware, and there we
are able to provide over 30,000 connections at any given time. On Linux
however select stops working after the first 1024 connections. I have
> For some reason shared memory is not being enabled on my system
> running kernel
> v2.4.0 (on RedHat v6.2, with all updates applied).
You are confusing System V shared memory (IPC) with VM shared memory. The
'0' for shared in /proc/meminfo means the system can't easily tell you how
For some reason shared memory is not being enabled on my system
running kernel
v2.4.0 (on RedHat v6.2, with all updates applied).
You are confusing System V shared memory (IPC) with VM shared memory. The
'0' for shared in /proc/meminfo means the system can't easily tell you how
much
> zsh: fork failed: resource temporarily unavailable
>
> on a machine. It has 510 processes which are mostly
> asleep, running under various user ids.
> How do I determine which resource is the problem so I can
> fix the shortage?
Sounds like processes/tasks is the resource in
zsh: fork failed: resource temporarily unavailable
on a machine. It has 510 processes which are mostly
asleep, running under various user ids.
How do I determine which resource is the problem so I can
fix the shortage?
Sounds like processes/tasks is the resource in question.
Cesar Barros wrote:
> On Mon, Dec 25, 2000 at 04:33:07PM -0800, David Schwartz wrote:
> > If the administrator of the NAT meant for you to have a
> > permanent mapping,
> > she would have put one there. Using keepalives to hold a NAT entry open
> > indefini
> On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
> > > This means that keepalive is useless for keeping alive more than
> > > one connection
> > > to a given host.
> > Actually, keepalive is useless for keeping connections
> > ali
On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
This means that keepalive is useless for keeping alive more than
one connection
to a given host.
Actually, keepalive is useless for keeping connections
alive anyway. It's
very badly named. It's purpose
Cesar Barros wrote:
On Mon, Dec 25, 2000 at 04:33:07PM -0800, David Schwartz wrote:
If the administrator of the NAT meant for you to have a
permanent mapping,
she would have put one there. Using keepalives to hold a NAT entry open
indefinitely without activity would be considered
> This means that keepalive is useless for keeping alive more than
> one connection
> to a given host.
Actually, keepalive is useless for keeping connections alive anyway. It's
very badly named. It's purpose is to detect dead peers, not keep peers
alive.
DS
-
To unsubscribe
This means that keepalive is useless for keeping alive more than
one connection
to a given host.
Actually, keepalive is useless for keeping connections alive anyway. It's
very badly named. It's purpose is to detect dead peers, not keep peers
alive.
DS
-
To unsubscribe from
> David Schwartz wrote:
> > The code does its best to estimate how much actual entropy it
> > is gathering.
> A potential weakness. The entropy estimator can be manipulated by
> feeding data which looks random to the estimator, but which is in fact
> not ra
David Schwartz wrote:
The code does its best to estimate how much actual entropy it
is gathering.
A potential weakness. The entropy estimator can be manipulated by
feeding data which looks random to the estimator, but which is in fact
not random at all.
-- Jamie
Sort
> I noticed peculiarities in the behaviour of the delta-delta-3 system for
> entropy estimation in the random.c code./ When I hold right alt
> or control, I
> get about 8 bits of entropy per repeat fro the /dev/random which is
> overestimated. I think the real entropy is 0 bits because it is
I noticed peculiarities in the behaviour of the delta-delta-3 system for
entropy estimation in the random.c code./ When I hold right alt
or control, I
get about 8 bits of entropy per repeat fro the /dev/random which is
overestimated. I think the real entropy is 0 bits because it is
> Last night I was browsing the web and I came across a page with
> LOTS of images. There were so many that it drove my swap space
> to ZERO. I still had 3 Meg of memory, but the system became
> virtually unusable and SLOW. (there were over 150 x 30k+ images
> on one page).
>
> Is this
Last night I was browsing the web and I came across a page with
LOTS of images. There were so many that it drove my swap space
to ZERO. I still had 3 Meg of memory, but the system became
virtually unusable and SLOW. (there were over 150 x 30k+ images
on one page).
Is this something that
> Little question about 'uname'. Does it read data from kernel, /proc or
> get its data from other source ?
'strace' was made to answer questions like this.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Little question about 'uname'. Does it read data from kernel, /proc or
get its data from other source ?
'strace' was made to answer questions like this.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
I noticed something odd with the entropy pool in 2.4.0-test11. If a normal
user does a 'sysctl -A', the entropy pool empties. I'm not sure why, but it
sounds like this isn't a good thing from a security standpoint.
DS
-
To unsubscribe from this list: send the line "unsubscribe
> [EMAIL PROTECTED] writes:
> > This looks like it's a bug to me although if you have multiple
> > threads hitting a file descriptor at the same time, you're pretty much
> > asking for trouble.
>
> Yes, I haven't been able to come up with an example that might trigger
> this that wasn't
[EMAIL PROTECTED] writes:
This looks like it's a bug to me although if you have multiple
threads hitting a file descriptor at the same time, you're pretty much
asking for trouble.
Yes, I haven't been able to come up with an example that might trigger
this that wasn't dubious to
> Now that it seems that George Bush has won the presidency, I am wondering
> whether Linus and other members of the free software community intend to
> leave the U.S. and go to more friendly places. Imagine what G.W. Bush is
> going to do to export controls, free software, copyright law,
Now that it seems that George Bush has won the presidency, I am wondering
whether Linus and other members of the free software community intend to
leave the U.S. and go to more friendly places. Imagine what G.W. Bush is
going to do to export controls, free software, copyright law, patent
> This way all should work. However someone mentioned that the returns
> from "malloc" should be unique. Why would that be? That would prohibit
> my "1" trick. The statement implies you want to go about checking
> pointers for equality. If for example you have a memcmp (a, b) that
> has "if (a
> > The program can't possibly work because it invokes undefined
> behavior. It
> > is impossible to determine what a program that invokes
> undefined behavior is
> > 'supposed to do'.
>
> I dont think it's undefined behaviour ...
You are correct. This is bahavior that is undefined by
This way all should work. However someone mentioned that the returns
from "malloc" should be unique. Why would that be? That would prohibit
my "1" trick. The statement implies you want to go about checking
pointers for equality. If for example you have a memcmp (a, b) that
has "if (a == b)
> hi,
> why does this program works. when executed, it doesnt
> give a segmentation fault. when the program requests
> memory, is a standard chunk is allocated irrespective
> of the what the user specifies. please explain.
>
> main()
> {
>char *s;
>s = (char*)malloc(0);
>
> From: "Dan Kegel" <[EMAIL PROTECTED]>
> > [EMAIL PROTECTED] asked:
> > > [Why does this program not crash?]
> > >
> > > main()
> > > {
> > >char *s;
> > >s = (char*)malloc(0);
> > >strcpy(s,"f");
> > >printf("%s\n",s);
> > > }
> >
> > It doesn't crash because the standard
> Now, if a module is loaded that registers a set of functions that have
> increased functionality compared to the original functions, if that
> modules is not based off GPL'd code, must the source code of that module
> be released under the GPL?
If the answer to this is "yes", then
Now, if a module is loaded that registers a set of functions that have
increased functionality compared to the original functions, if that
modules is not based off GPL'd code, must the source code of that module
be released under the GPL?
If the answer to this is "yes", then
> * David Schwartz <[EMAIL PROTECTED]> [001025 15:35] wrote:
> >
> > If a programmer does not ever wish to block under any
> circumstances, it's
> > his obligation to communicate this desire to the
> implementation. Otherwise,
> > the implementation can bloc
* David Schwartz [EMAIL PROTECTED] [001025 15:35] wrote:
If a programmer does not ever wish to block under any
circumstances, it's
his obligation to communicate this desire to the
implementation. Otherwise,
the implementation can block if it doesn't have data or an
error available
> On Wed, Oct 25, 2000 at 03:11:37PM -0700, David Schwartz wrote:
> >
> > > Now, next time around the loop, we get a notification for an event
> > > when there is no data to read. The application now must be prepared
> > > to handle this case (meaning
> Now, next time around the loop, we get a notification for an event
> when there is no data to read. The application now must be prepared
> to handle this case (meaning no blocking read() calls can be used).
> --
> Jonathan
If the programmer never wants to block in a read call, he
Now, next time around the loop, we get a notification for an event
when there is no data to read. The application now must be prepared
to handle this case (meaning no blocking read() calls can be used).
--
Jonathan
If the programmer never wants to block in a read call, he should
On Wed, Oct 25, 2000 at 03:11:37PM -0700, David Schwartz wrote:
Now, next time around the loop, we get a notification for an event
when there is no data to read. The application now must be prepared
to handle this case (meaning no blocking read() calls can be used
> I'm trying to write a server that handles 1 clients. On 2.4.x,
> the RT signal queue stuff looks like the way to achieve that.
> Unfortunately, when the RT signal queue overflows, the consensus seems
> to be that you fall back to a big poll(). And even though the RT signal
> queue
> Under Solaris 7, when the number of idle sockets was increased from
> 100 to 1, the time to check for active sockets with poll()
> increased by a factor of only 6.5. That's a sublinear increase in time,
> pretty spiffy.
Under Solaris 7, when the number of idle sockets was decreased from
Under Solaris 7, when the number of idle sockets was increased from
100 to 1, the time to check for active sockets with poll()
increased by a factor of only 6.5. That's a sublinear increase in time,
pretty spiffy.
Under Solaris 7, when the number of idle sockets was decreased from
I'm trying to write a server that handles 1 clients. On 2.4.x,
the RT signal queue stuff looks like the way to achieve that.
Unfortunately, when the RT signal queue overflows, the consensus seems
to be that you fall back to a big poll(). And even though the RT signal
queue [almost]
> [EMAIL PROTECTED] said:
> > There is NOT a bug in the JVM code that handles java.net.DatagramSock
> > et. Don't you find it a little compelling that the nearly identical
> > JVM code passes the Java Compatibility test suite on Linux 2.2,
> > Solaris, HPUX, SCO, and even Windows?
>
> If the
[EMAIL PROTECTED] said:
There is NOT a bug in the JVM code that handles java.net.DatagramSock
et. Don't you find it a little compelling that the nearly identical
JVM code passes the Java Compatibility test suite on Linux 2.2,
Solaris, HPUX, SCO, and even Windows?
If the JVM spec
> Due ot this and other reasons I'm restoring the 2.2.x behavior by
> default, but adding a sysctl so that systems using dynamic addressing
> may elect to get the different bind() behavior.
>
> Later,
> David S. Miller
> [EMAIL PROTECTED]
If a system uses dynamic addressing, binding to
Due ot this and other reasons I'm restoring the 2.2.x behavior by
default, but adding a sysctl so that systems using dynamic addressing
may elect to get the different bind() behavior.
Later,
David S. Miller
[EMAIL PROTECTED]
If a system uses dynamic addressing, binding to an IP
> The XNS specification seems loose enough to allow the Linux
> behaviour. I don't
> think we should however adopt it as default behaviour. Programs
> that dont care
> about addresses use INADDR_ANY.
>
> Alan
I worry that an application may use ability to bind to determine whether an
The XNS specification seems loose enough to allow the Linux
behaviour. I don't
think we should however adopt it as default behaviour. Programs
that dont care
about addresses use INADDR_ANY.
Alan
I worry that an application may use ability to bind to determine whether an
address
> I've filed lots of patents in my day Marty -- this is correct. I have
> two patent lawyers on staff. Want to try again..
>
> Jeff
> > And you only get the year of protection **IF** you have filed a
> > provisional patent application, which expires 12 months after it's
> > issued. You must
I've filed lots of patents in my day Marty -- this is correct. I have
two patent lawyers on staff. Want to try again..
Jeff
And you only get the year of protection **IF** you have filed a
provisional patent application, which expires 12 months after it's
issued. You must then file
> I've heard comments from Alan, and others in the past bashing
> threads, and I can understand the "threads are for people who
> can't write state machines" comments I've heard, but what other
> ways are there of accomplishing the goals that threads solve in
> an acceptable manner that gives
I've heard comments from Alan, and others in the past bashing
threads, and I can understand the "threads are for people who
can't write state machines" comments I've heard, but what other
ways are there of accomplishing the goals that threads solve in
an acceptable manner that gives good
> 3rd Problem: one uid/gid process-wide
>
> All the ID (uid/guid/euid/egid/...) must be process wide. The problem
> is similar to the signal handler. I think one should again keep the
> information exclusively in the master thread and have all others refer
> to this information.
Other
3rd Problem: one uid/gid process-wide
All the ID (uid/guid/euid/egid/...) must be process wide. The problem
is similar to the signal handler. I think one should again keep the
information exclusively in the master thread and have all others refer
to this information.
Other than
601 - 676 of 676 matches
Mail list logo
