Linux-Development-Sys Digest #853, Volume #7 Sun, 14 May 00 01:13:09 EDT
Contents:
Gettimeofday (pramodh mallipatna)
Possible 2.3.99pre6 problem (bill davidsen)
Re: Linux (thread vs fork) (Bryan Hackney)
Lucent WaveLan Hardware Information? ("Robert Nilsson")
Re: ANSI C & void main() (Kaz Kylheku)
Re: ANSI C & void main() (Kaz Kylheku)
Re: ANSI C & void main() (Kaz Kylheku)
Re: ANSI C & void main() (Kaz Kylheku)
/proc/pid/stat array.c question (Eric Taylor)
Re: 100 Mb thernet PCI on a 486 DX2 66MHz? (Stefaan A Eeckels)
Re: Linux (thread vs fork) (Stefaan A Eeckels)
Re: ANSI C & void main() (Chris F.A. Johnson)
Re: ANSI C & void main() ("Mark Graybill")
Re: ANSI C & void main() ("Mark Graybill")
----------------------------------------------------------------------------
From: pramodh mallipatna <[EMAIL PROTECTED]>
Subject: Gettimeofday
Date: 13 May 2000 21:48:58 GMT
Hi,
I have a problem with gettimeofday().
I do something like this.
gettimeofday(&startTime, &tz);
do_stuff();
gettimeofday(&endTime, &tz);
When I take the difference between endTime and startTime, I normally
get correct results...but sometimes, startTime is greater than endTime and
hence I get negative time difference...
do_stuff() takes non-zero amount of time...I even tried this stopping my
xntpd so as to rule out its effect. But still, I have the problem.
Any suggestions about what is happening?
Thanks,
Pramodh
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Possible 2.3.99pre6 problem
Date: 13 May 2000 22:08:58 GMT
I have a reproducable problem on one system, and won't be able to try
on another until Monday at the earliest, so take this as a request for
confirmations and/or warning of a possible problem.
I tried to mount an ISO filesystem in a file, using a loopback mount,
read only, on an SMP system, without specifying the file type. The
system hung in an odd mode, I could execute nothing but could log in.
Then I tried specifying the filesystem type, -t iso9660, and the mount
completed, but it hung when I tried to copy a file out of the mounted
f/s to another f/s.
This did not happen on a uniprocessor system. I only have four systems
with pre6, and one is down while the other is running a big job over the
weekend.
I also was unable to format a floppy on the SMP system using
superformat. However, the system has been doing a numerical analysis
problem for over a week on pre6, so it has been relatively stable.
At this point please note "possible" problem, but solidly happening on
that system.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"Doing interesting things with little computers since 1979"(tm)
The hardest test of maturity is knowing the difference between
resisting temptation and missing a once-in-a-lifetime opportunity.
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: Linux (thread vs fork)
Date: Sat, 13 May 2000 18:01:56 -0500
[EMAIL PROTECTED] wrote:
>
> As long as I know linux maps threads as processes.
> My question is that if linux maps threads as processes
> is there an advantage of using threads.
> It seems to be threading in linux is not a good idea,
> or is it?
>From what I understand, a context switch between threads is
cheaper than a context switch between processes.
> For example there is a limit for the number of threads
> per process. On the other hand the limit for the number
> of processes is larger. I know that Apache uses preforking
> , but there are some other web servers (Trantula) which
> uses other techniques. Consequently I am confused with this.
> My goal is to write a scalable chat server. The throughput
> is the most important issue in the project. In this case
> what is the best way?
> Another question is that, is there an efficient way for select (or poll)
> in unix. I want to do the same thing that the select does, but I do not
> want the penalty (two system calls) of select.
I'm reading between the lines here, but I would suggest doing blocking
reads in a dedicated reader thread. I've done that several times. Works
fine. But that probably won't scale to hundreds or thousands of connections.
>
> Thanks a lot for the answers?
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
Bryan Hackney / BHC / [EMAIL PROTECTED]
http://www.FreeClassAds.com/
http://bhconsult.com/
http://bhconsult.com/bh/pgp.key
------------------------------
Subject: Lucent WaveLan Hardware Information?
From: "Robert Nilsson" <[EMAIL PROTECTED]>
Date: Sat, 13 May 2000 23:45:38 GMT
Hello!
I'm working on adapting a LAN printserver to wireless LAN using
Lucent Tech's Wavelan network card. I'm having problems finding
hardware information about this card. Anyone who knows where I can
get that kind of information?
Thanks in advance!
Robert Nilsson
Axis Communcations AB
--
========================================================================
Posted with Amiga NewsRog
========================================================================
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: ANSI C & void main()
Reply-To: [EMAIL PROTECTED]
Date: Sat, 13 May 2000 20:52:24 GMT
On Sat, 13 May 2000 13:02:00 GMT, Frank <[EMAIL PROTECTED]> wrote:
>So Linux doesn't support the struct return type. If I wrote an OS, Bigix, that
Right. My point was that not only does gcc it not support it, it produces an
executable anyway; a bad one. This was a counterexamle to the claim that a
compiler must stop compiling if it sees an unsupported form of main.
>fails to understand int returns and only supports struct returns then are you
>suggesting that I could never use C?
That implementation would not be a conforming hosted implementation of C,
because it would not properly accept conforming C programs.
You could use C, just not standard C.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: ANSI C & void main()
Reply-To: [EMAIL PROTECTED]
Date: Sat, 13 May 2000 20:57:06 GMT
On Sat, 13 May 2000 15:28:49 GMT, Frank <[EMAIL PROTECTED]> wrote:
>^ >So, void main() IS allowable according to the current ANSI C++ standard.
>^
>^ follow from the above quote? ;-)
>---------------------------------------
>
> "[... The main function] shall have a return type of type int...
>
>This addresses the type of the returned object, not how main() is defined.
Doh, the two are not inseparable. The return type is part of the type of a
function. The above clearly states that the function shall have a certain
return type.
> "...but otherwise its type is implementation-defined. [...]"
>
>Not it's addressing the type of main().
Nope, now it's merely saying that other int-returning forms may be accepted.
There may be variance in the argument types.
Note that this is from the bleeding-edge 1999 standard. The wording differs
from the 1989 standard which most compilers still follow.
>It's saying that the type of main() shall not hard coded by any
>implementation. Not even type 'int'. It's also saying that main() will always
>return 'int'. From this, void main() is permitted but main() shall return
>'int'.
Explain how main can return int if its return type has been declared
void? Returning a value in a function that returns nothing is a constraint
violation; it requires a diagnostic.
>void main(void)
>{
> printf("Hello world!\n");
>}
>
>This program meets those requirements because of the message portion you did
>not quote:
>
>^ ...and paragraph 5 reads:
>
>^ "A return statement in main has the effect of leaving the main
>^ function (destroying any objects with auto�matic storage duration)
>^ and calling exit with the return value as the argument. If
>^ control reaches the end of main without encountering a return
>^ statement, the effect is that of executing return 0;"
>
That assumes that main has been correctly declared to return int.
Since it has not, the behavior is undefined and the text above does
not apply.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: ANSI C & void main()
Reply-To: [EMAIL PROTECTED]
Date: Sun, 14 May 2000 01:10:39 GMT
On Sat, 13 May 2000 18:58:17 GMT, Frank <[EMAIL PROTECTED]> wrote:
>Erik Max Francis <[EMAIL PROTECTED]>...
>^ Frank wrote:
>^ > ... (but so is 'void main()').
>^
>^ Not sure what you meant here.
>
>I meant that 'void main()' returns an integer according to the standard cited
>by Mark Graybill.
Only if you apply a sixth grade or lower level of reading comprehension to the
text.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: ANSI C & void main()
Reply-To: [EMAIL PROTECTED]
Date: Sun, 14 May 2000 01:20:12 GMT
On 13 May 2000 21:19:05 +0100, Chris J/#6 <[EMAIL PROTECTED]> wrote:
>Now - I would presume that gcc would have barfed if it was illegal behaviour,
>not just warned. Is this classed as broken behaviour or not?
No; the program you wrote doesn't violate any syntax or constraint rule. The
standard requires only constraint and syntax rules to be diagnosed, so the
warning you got from gcc is a ``bonus''.
Moreover, the standard does not require the implementation to stop translating
under any circumstances. Even programs with syntax errors can be turned into
executables, so long as the required diagnostic is emitted. It's up to the
programmer or user of the program to heed the diagnostics.
Here is an example: implicit conversions among incompatible pointers are a
constraint rule violation. The GNU compiler merely emits a warning for such
conversions, and produces a translation anyway. This constraint violation is as
serious as any other; the standard doesn't discern among severity levels like
``warning'' or ``error''.
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: /proc/pid/stat array.c question
Date: Sat, 13 May 2000 18:42:29 -0700
hi:
I want to make /proc/pid/stat report the current frame pointer
on a 386 system. I see two macros used by array.c
#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned
long)(tsk)))[1019])
#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned
long)(tsk)))[1022])
which i can't figure out. I tried adding my own for the ebp
register and set the value of the array from 1015 thru 1025 to
no avail.
It seems the registers are not saved in the task struct, but
at the above magic offsets. Can someone explain what that
code does, and maybe give me a hint as to where i might find
the saved frame pointer??
thanks
e
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: 100 Mb thernet PCI on a 486 DX2 66MHz?
Date: Sun, 14 May 2000 01:21:14 +0200
In article <8fk56i$mgi$[EMAIL PROTECTED]>,
Mark Hahn <[EMAIL PROTECTED]> writes:
>> with the cheap ones (10MB/s was common for fast SCSI drives
>> used in those days).
>
> it was _not_ common for SCSI drives to sustain 10 MB/s in 486 days.
It was common for _fast_ SCSI drives to run at 10MB/s.
My 486 EISA/Adaptec 2740 SCSI/HP 1GB Fast SCSI server (1993)
did 10MB/s from the disk to the controller, and about 8MB/s
under Linux 2.0.36.
--
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] (Stefaan A Eeckels)
Subject: Re: Linux (thread vs fork)
Date: Sun, 14 May 2000 01:23:13 +0200
In article <8fj2to$45t$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
> As long as I know linux maps threads as processes.
> My question is that if linux maps threads as processes
> is there an advantage of using threads.
The advantage is the thread semantics, and the fact that
somewhat less state information needs to be stored between
thread switches.
Linux switches processes as fast or faster than NT
switches threads, so there isn't too much to be gained
in terms of performance.
> It seems to be threading in linux is not a good idea,
> or is it?
When your applications needs threads, by all means use
them. One instance would be the necessity to have a
shared address space.
But conceptually, separate forked processes (ie sharing
a common state through the fork) is a lot easier to
handle than threading.
> For example there is a limit for the number of threads
> per process. On the other hand the limit for the number
> of processes is larger. I know that Apache uses preforking
> , but there are some other web servers (Trantula) which
> uses other techniques. Consequently I am confused with this.
People tend to find solutions for those aspects they find
bothersome. Whether these are genuine problems depends on
the situation.
> My goal is to write a scalable chat server. The throughput
> is the most important issue in the project. In this case
> what is the best way?
You'd have to ask what limits to scalability you're prepared
to accept. There are limits on open files, select descriptors,
task switching overheads, etc. The best solution is the one that
balances the capability of the machine with the requirements
of the program.
> Another question is that, is there an efficient way for select (or poll)
> in unix. I want to do the same thing that the select does, but I do not
> want the penalty (two system calls) of select.
Select is efficient (or as efficient as you're likely to get in
a stock UNIX system).
--
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] (Chris F.A. Johnson)
Subject: Re: ANSI C & void main()
Date: Sun, 14 May 2000 02:30:41 GMT
On Sat, 13 May 2000 06:09:01 GMT, Mark Graybill ([EMAIL PROTECTED]) wrote:
: In the current C++ ANSI standard (ICO-IEC 14882) section 3.6.1, paragraph 2
: reads:
Are you discussing C or C++? The subject line says ANSI C, but you quote
the C++ standard. Different animal.
: "An implementation shall not predefine the main function. This function
: shall not be overloaded. It shall
: have a return type of type int, but otherwise its type is
"It shall have a return type of type int," sounds pretty definitive to me:
not void, not float, not ..., but "int".
--
Chris F.A. Johnson
[EMAIL PROTECTED] http://members.home.net/c.f.a.johnson
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Everything in moderation - including moderation
------------------------------
Reply-To: "Mark Graybill" <[EMAIL PROTECTED]>
From: "Mark Graybill" <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: Sun, 14 May 2000 04:58:11 GMT
Kaz Kylheku wrote in message ...
>It does not say ``as a minimum''. I don't infer any implicit or explicit
>encouragement for the support of other forms from the text.
The question isn't one of encouragement, but allowance. IOW, void main() is
NOT illegal, and it's behavior IS defined.
>which means they are *not required* to support any others, nor to define
the
>behavior of any others in any way.
>
>Yes it is allowable. It is allowable for an *implementation* to support
it.
Oh, so you agree.
>However, we are talking about using the language, not implementing it.
We are talking about both. We use void main(), which is ANSI comliant IF
the implementation allows it; and the implementation (compiler) determines
the behavior after it returns.
Regardless of what the compiler allows through as a type of main, if a value
is not returned, the behavior is defined.
>The behavior of programs which use an alternate form is undefined in the
>standard. They are in the hands of the implementor.
Yes, and as long as <other than int type> main() returns a value, the
behavior is not defined by the ANSI C++ standard. If they do not return a
value (either no return statement, or a return statement with no value),
then the behavior is defined.
>There are plenty of other undefined behaviors in the language that are
>used as a basis for extensions.
The behavior everyone is speaking of is that of post main() execution. The
standard clearly states that if a return statement does not exist in main()
(or a value is not returned), that the implementation shall treat it as if a
"return 0;" was executed.
So regardless of implementation specifics of the type of main(), return 0 is
supposed to be the default if a return code is not passed to the calling
code. (which is within the program binary - e.g. crt0.)
>>The behavior is NOT undefined because the type of main() only is important
>>when it returns to it's calling code.
>
>You don't seem to understand what calling conventions are all about. When
the
>type of a call does not match the function definition, there is no telling
>whether the call will fail, or whether the return will fail or what happens
at
>all.
If there was a function definition to match, then the linker would choke
with an undefined external. In most C compilers, the calling code is
primative and only performs a 'call [<addr of main>]'. It could careless
about the calling convention. It's interest is to generate code that either
pops the return code off the stack, or code that does not. If main()
doesn't return a value, then a return code is not pushed on the stack and is
not available. Therefore, the compiler will not generate the code to
retrieve the value (e.g. pop [<register to hold exit code>]), but it must
act as if return 0 was executed.
Most C++ compilers are more strongly typed, and therefore won't even compile
types of main that are larger than a single push/pop.
>Try feeding your compiler this:
>
> struct foo {
> char x[500];
> } main(int argc, char **argv)
> {
> struct foo retval = { 0 };
> return retval;
> }
The argument is one of void main(). With void, you cannot return a value,
so the calling code is supposed to act as if main() returned a value of 0
(paragraph 5.)
If you try the above code, but do not return a value, it doesn't core dump.
This is because the calling code is acting as if it received a return 0 (int
return type is implied from the previous text), just as the standard
specifies. IOW, it will not pop the return code off the stack if main()
doesn't return a value.
In your code above, the state of the stack existing when main() returns to
the calling code is not what the calling code expects, which caused the core
dump.
>Chances are that it won't stop compiling and you will get an executable.
Does
>that mean that your compiler supports the returning of a big structure from
>main? Can you cite this support from your compiler's documentation?
>
>I ran the above program on a GNU/Linux system and it produced an a.out.
>It died with a core dump. Hmm, it doesn't look like this is a supported
>form for main, so why did it pass compilation? Is GCC not conforming?
Actually, gcc doesn't have to conform to the ANSI C++ standard because it is
a C compiler, but g++ does. (BTW, g++ will not compile the code above.)
But it will compile void main().
-Mark
------------------------------
Reply-To: "Mark Graybill" <[EMAIL PROTECTED]>
From: "Mark Graybill" <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: Sun, 14 May 2000 05:01:51 GMT
Frank wrote in message <01bfbd0f$9ee91de0$0125250a@ockkntlokp>...
>Erik Max Francis <[EMAIL PROTECTED]>...
>So then there is a problem with sticking to the standard in some instances.
>The standard does allow for easily portable code but I have never needed
>portable code in anything I've done. Portability is certainly essential in
>many cases but it is also unnecessarily restrictive in others. If I wrote
this
>Bigix operating system the standard would eventually be changed to allow
for
>it, but in the interim no code will be written for it by anyone unable to
look
>beyond the standards. Those who do write code for it will be setting the
>standard.
>
>My point here is that the standard is a guide, not the law.
You are safer developing to the standard, than if not. This is why I use
the C++ STL instead of MFC (for my Winblows work.)
It is possible that a compiler will not support void main(), which means it
should produce a compiler error.
But if it compiles and creates an executable, then if it is to remain ANSI
compliant, it must act as if main() returns a value of 0.
-Mark
------------------------------
** 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
******************************
