Linux-Development-Sys Digest #966, Volume #7 Wed, 21 Jun 00 18:13:17 EDT
Contents:
Re: read(2) error EINTR (Alex Hooker)
Re: wm creation (Bob Hauck)
Re: read(2) error EINTR ("Paul D. Smith")
Re: read(2) error EINTR ([EMAIL PROTECTED])
Re: function to get current year (tye4)
Re: function to get current year (David A. Lethe)
Re: bootlogos (John Gluck)
Re: function to get current year (Erik Max Francis)
Re: function to get current year (Erik Max Francis)
Re: read(2) error EINTR ("Paul D. Smith")
Re: function to get current year ("Paul D. Smith")
Re: read(2) error EINTR ([EMAIL PROTECTED])
Re: Unable to delete recursive symlink (Nix)
QUERY: swap to/from a char device? (Tom Roberts)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Alex Hooker)
Subject: Re: read(2) error EINTR
Date: 21 Jun 2000 17:56:27 GMT
Alan Donovan ([EMAIL PROTECTED]) wrote:
: Alex Hooker wrote:
: >
: > I am just doing some testing on linux system calls,
: > and I just can't seem to get read to generate the
: > EINTR error. Ideally, on a blocking empty pipe read,
: > you would get this error - fork() child blocks on the
: > read and the parent sends constant EINTR signals via
: > kill(). But the child does not terminate. I am using
: > signal() to catch...
: If you want to get read() to generate this error, read on some fd for
: more data than is available, so that it blocks, then send the process a
: signal (e.g. SIGUSR1, SIGINT, whatever). I'm not familiar with the
: situation you descibe; to me, EINTR means "blocking call prematurely
: returned due to signal delivery".
I believe I tried this, and even with blocking pipes, read returns
only the number of bytes successfully read. I said read 30. There
was only 1 in there, and it took the one and didn't wait on the rest.
: BTW for some reason signal() is frowned upon. Long lunch an' all that.
: Can't remember why, but sigaction is recommended instead.
Long lunch? That sheds no light for me...
al
------------------------------
From: [EMAIL PROTECTED] (Bob Hauck)
Subject: Re: wm creation
Reply-To: hauck[at]codem{dot}com
Date: Wed, 21 Jun 2000 18:54:04 GMT
On Wed, 21 Jun 2000 10:45:21 -0500, Bill <[EMAIL PROTECTED]> wrote:
>Anyone seen a web page that could direct me in the ways of building a window
>manager for Linux in C or C++
Blackbox is a "simple" window manager in C++. The source code is only
about 550kB, under 19K lines according to wc.
<http://blackbox.alug.org/>
--
-| Bob Hauck
-| Codem Systems, Inc.
-| http://www.codem.com/
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: read(2) error EINTR
Date: 21 Jun 2000 15:02:57 -0400
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED] (Alex Hooker) writes:
ah> Alan Donovan ([EMAIL PROTECTED]) wrote:
ah> : Alex Hooker wrote:
ah> : >
ah> : > I am just doing some testing on linux system calls,
ah> : > and I just can't seem to get read to generate the
ah> : > EINTR error. Ideally, on a blocking empty pipe read,
ah> : > you would get this error - fork() child blocks on the
ah> : > read and the parent sends constant EINTR signals via
ah> : > kill(). But the child does not terminate. I am using
ah> : > signal() to catch...
EINTR is an error message, not a signal; maybe you meant SIGINT?
Anyway, you'll need to give a more detailed description of exactly what
you're doing. Maybe you can provide a little program. Signal() is
tricky to use, and a lot depends on how you set it up.
As Alan Donovan mentioned, sigaction() is much more reliable and
functional.
ah> I believe I tried this, and even with blocking pipes, read returns
ah> only the number of bytes successfully read. I said read 30. There
ah> was only 1 in there, and it took the one and didn't wait on the
ah> rest.
It will always do that; that's how read(2) is defined and how it's
supposed to work. See the man page for read(2); mine says:
On success, read() and readv() return the number of bytes actually
read and placed in the buffer; this number may be less than nbyte if
the file is associated with a communication line (see ioctl(2) and
termio(7I)), or if the number of bytes left in the file is less than
nbyte, or if the file is a pipe or a special file. A value of 0 is
returned when an end-of-file has been reached.
If you want to block until you've read 30 bytes, you need to check how
many bytes you got and loop if you didn't get enough. read(2) will
block if there are no bytes to be read. Be sure to check the return for
-1 and 0 and handle those cases.
Note that this comments seems completely different than the issue you
raised first above, though, regarding signals... I'm confused about
exactly what the problem is that you're having.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: read(2) error EINTR
Date: Wed, 21 Jun 2000 19:29:23 GMT
Paul D. Smith <[EMAIL PROTECTED]> wrote:
> As Alan Donovan mentioned, sigaction() is much more reliable and
> functional.
EINTR dates from the days before system calls were automatically
restarted. On more modern implementations, read(2) is almost always
restarted. It may be posible to disable that by removing SA_RESTART
from sa_flags while using POSIX.1 signals, but I'm not 100% sure. In
any case, it's bound to be nonportable. I believe at least 4.2BSD
unconditionally restarted reads and writes.
The real issue is what situation you would want system calls to not be
restarted in. I suspect there's a much cleaner way of achieving
whatever you're trying to attempt.
In any case, you definately want to avoid signal() at all costs and
use sigaction and friends. Even more important than reliability or
functionality is the fact that they have well-defined behavior which
signal() does not.
> ah> I believe I tried this, and even with blocking pipes, read returns
> ah> only the number of bytes successfully read. I said read 30. There
> ah> was only 1 in there, and it took the one and didn't wait on the
> ah> rest.
The count argument to read(2) specifies the maximum number of bytes to
read, it's up to you to check the return value and see if you've
gotten all 30 bytes. If you look at the man page:
It is not an error if this number is smaller than the number of
bytes requested; this may happen for example if fewer bytes are
actually available right now (maybe because we were reading
from a pipe, ...
> If you want to block until you've read 30 bytes, you need to check how
> many bytes you got and loop if you didn't get enough. read(2) will
> block if there are no bytes to be read. Be sure to check the return for
> -1 and 0 and handle those cases.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: tye4 <[EMAIL PROTECTED]>
Subject: Re: function to get current year
Date: Wed, 21 Jun 2000 12:51:02 -0700
What about systems that have a 32-bit time_t? Is there any way to get a _at
least_ a four digit year? I would prefer a 32-bit year that would rollover
in 4 billion years.
-tye4
Erik Max Francis wrote:
>
> And why would you only want a four-digit number? That rolls over in
> 10 000 AD.
>
> The answer is, yes, you want to use the ANSI C time functions. If you
> write it in conformance with the Standard, then all you need to do is
> compile your program on a machine that uses a 64-bite time_t (or what
> have you), and you'll be done with it.
>
------------------------------
From: [EMAIL PROTECTED] (David A. Lethe)
Subject: Re: function to get current year
Date: Wed, 21 Jun 2000 20:09:45 GMT
On Wed, 21 Jun 2000 12:51:02 -0700, tye4 <[EMAIL PROTECTED]> wrote:
>What about systems that have a 32-bit time_t? Is there any way to get a _at
>least_ a four digit year? I would prefer a 32-bit year that would rollover
>in 4 billion years.
>
>-tye4
32-bit year?!!
Our sun won't even last that long!
------------------------------
From: John Gluck <[EMAIL PROTECTED]>
Subject: Re: bootlogos
Date: Wed, 21 Jun 2000 16:03:56 -0400
Gordon Morison wrote:
> My apologies if this is not the right group to be posting this to.
>
> Can someone explain to me what the framebuffer is?
>
> I am trying to patch the kernel (2.2.14) to display an alternative logo and
> I am getting no where so any help would be greatly appreciated.
>
> Thanks in advance
>
> Gordon Morison
It's essentialy a memory buffer for graphics. If you compile it into the
kernel, the console will operate using graphics mode for text.
On bootup you will see "a cute penguin logo" (quoted from a doc I read
somewhere) at the top of your screen.
--
John Gluck (Passport Kernel Design Group)
(613) 765-8392 ESN 395-8392
Unless otherwise stated, any opinions expressed here are strictly my own
and do not reflect any official position of Nortel Networks.
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Subject: Re: function to get current year
Date: Wed, 21 Jun 2000 13:34:33 -0700
"David A. Lethe" wrote:
> 32-bit year?!!
> Our sun won't even last that long!
Not quite. The Sun is about halfway through its main sequence lifetime
of 10 Gy, and a 32-bit year counter could hold about 4.2 Gy.
The Sun will steadily brighten as it expends the hydrogen in its core
(all while staying on the main sequence), and in only a few hundred My
the Sun will have brightened to the point where the Earth's biosphere
won't be able to withstand it, and you'll have a runaway greenhouse
effect, like Venus (all provided there is no intelligent intervention on
Earth's behalf, of course).
So a 32-bit year won't outlive the Sun, but it will outlive the Earth's
usefulness as a home for humanity.
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ When angry, count four; when very angry, swear.
\__/ Mark Twain
blackgirl international / http://www.blackgirl.org/
The Internet resource for black women.
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Subject: Re: function to get current year
Date: Wed, 21 Jun 2000 13:31:52 -0700
tye4 wrote:
> What about systems that have a 32-bit time_t? Is there any way to get
> a _at
> least_ a four digit year? I would prefer a 32-bit year that would
> rollover
> in 4 billion years.
It is unclear to me what you're asking, and I suspect that you're asking
for something you can't have, without knowing that what you're looking
for is unnecessary in the first place.
A 32-bit time_t can only hold dates to about 2038 (as you yourself
pointed out earlier). If you're asking for a four-digit year meaning
one that is valid past 1999, then you obviously already have one. If
you're asking for a four-digit year meaning one that is valid up until
9999 AD, then a 32-bit time_t cannot possibly give you that.
Use the Standard time routines as they exist. They will be valid until
2038, by which point all you'll need to do is recompile your
Standard-compliant routines on an operating system that has an expanded
time_t, and your time values will be valid up until the point at which
that expanded time_t runs out.
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ When angry, count four; when very angry, swear.
\__/ Mark Twain
blackgirl international / http://www.blackgirl.org/
The Internet resource for black women.
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: read(2) error EINTR
Date: 21 Jun 2000 16:59:02 -0400
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED] writes:
e> Paul D. Smith <[EMAIL PROTECTED]> wrote:
>> As Alan Donovan mentioned, sigaction() is much more reliable and
>> functional.
e> EINTR dates from the days before system calls were automatically
e> restarted. On more modern implementations, read(2) is almost always
e> restarted. It may be posible to disable that by removing SA_RESTART
e> from sa_flags while using POSIX.1 signals, but I'm not 100% sure. In
e> any case, it's bound to be nonportable.
Note SA_RESTART isn't in POSIX, although it is in SingleUNIX.
System calls _aren't_ automatically restarted, in general.
I'm not sure what systems you're referring to by "modern
implementations", but in my experience, almost all current UNIX
implementations of read(2) _aren't_ restarted, although most do provide
ways to do so (such as SA_RESTART, as you mention). For example,
Solaris doesn't restart, HP-UX doesn't restart, Linux doesn't restart,
I'm pretty sure AIX doesn't but I can't check right now, etc.
In POSIX, read() doesn't restart. In SingleUNIX, read() doesn't
restart.
I believe it's mainly BSD-derived systems that restart automatically.
In short, assuming that read() doesn't restart is much more portable
than assuming that it does.
e> The real issue is what situation you would want system calls to not
e> be restarted in. I suspect there's a much cleaner way of achieving
e> whatever you're trying to attempt.
Consider a set of servers that can start a certain number of jobs
(subprocesses) between them. To manage this they all have a pipe they
share containing a token for each job that can be started. When a server
finishes a job, it puts the token back in the pipe. When a server wants
to start a job, it reads a token from the pipe.
If reads don't interrupt on SIGCHLD you can deadlock where every server
is trying to get a token, and none of them can process any jobs that
have finished.
select(2) doesn't work, because between the time your select returns
saying you have data and the time you invoke the read() to get the data,
someone else could have grabbed your token. The read() is atomic: if it
returns with a token you got it, otherwise you didn't.
ah> I believe I tried this, and even with blocking pipes, read returns
ah> only the number of bytes successfully read. I said read 30. There
ah> was only 1 in there, and it took the one and didn't wait on the
ah> rest.
e> The count argument to read(2) specifies the maximum number of bytes to
e> read, it's up to you to check the return value and see if you've
e> gotten all 30 bytes. If you look at the man page:
e> It is not an error if this number is smaller than the number of
e> bytes requested; this may happen for example if fewer bytes are
e> actually available right now (maybe because we were reading
e> from a pipe, ...
I'm not sure how that differs from what I said, but thanks for the
reinforcement :).
>> If you want to block until you've read 30 bytes, you need to check how
>> many bytes you got and loop if you didn't get enough. read(2) will
>> block if there are no bytes to be read. Be sure to check the return for
>> -1 and 0 and handle those cases.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: function to get current year
Date: 21 Jun 2000 17:12:25 -0400
Reply-To: [EMAIL PROTECTED]
%% tye4 <[EMAIL PROTECTED]> writes:
t> What about systems that have a 32-bit time_t? Is there any way to
t> get a _at least_ a four digit year? I would prefer a 32-bit year
t> that would rollover in 4 billion years.
time_t represents the number of _seconds_ since the Epoch (Jan 1, 1970).
If time_t is a 32-bit signed value (as almost all are right now) then it
will wrap in 2038 sometime, ~2 billion seconds after Jan 1, 1970.
The idea is that by the time 2038 comes around, all the current versions
of UNIX/POSIX using a 32-bit time_t will be obsolete, and time_t will
have long since migrated to a 64-bit value, which can handle 4 billion
years and a _lot_ more.
When you format a time_t value, you get back a year which is the real
year minus 1900. You can add 1900 to that to get back the real year.
That year value is an int, which by the standard must be at least a
16-bit value, so you're guaranteed years up to 65535+1900, or 67435 (if
time_t can represent that).
In reality, on most systems today an int is 32 bits, which gives you
your 4 billion years.
The time_t value should be an internal, runtime value: in a portable
program you never want to save raw time_t values anywhere, at least not
anywhere that's expected to last long-term. If you do then when your
system upgrades to a 64-bit time_t, those values won't be readable (at
least not without munging). Format the time_t value and save the
formatted version, instead: that's the portable way to go.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: read(2) error EINTR
Date: Wed, 21 Jun 2000 21:40:21 GMT
Paul D. Smith <[EMAIL PROTECTED]> wrote:
> I believe it's mainly BSD-derived systems that restart automatically.
> In short, assuming that read() doesn't restart is much more portable
> than assuming that it does.
That's true. I believe that on at least some SysV systems you actually
get varyinging behavior depending on which of the signal functions you
use. That is, you can get the BSD style ones "accidently." The morale
of the story (which I meant to convey in the original post) is to
always use sigaction, and not assume anything about system calls
restarting or not restarting.
> select(2) doesn't work, because between the time your select returns
> saying you have data and the time you invoke the read() to get the data,
> someone else could have grabbed your token. The read() is atomic: if it
> returns with a token you got it, otherwise you didn't.
The problem here still seems to me that process are writing and
reading willy nilly from the pipe. You could use a locking scheme to
prevent this sort of nastiness, or use a different communication
scheme all together.
> I'm not sure how that differs from what I said, but thanks for the
> reinforcement :).
It actually doesn't differ at all. ;) The point I wanted to make was
even a cursory examination of the man page would have pointed out the
answer to the exact problem described. ie, reading from a pipe
returning 1 out of 30 bytes.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: uk.comp.os.linux
Subject: Re: Unable to delete recursive symlink
Date: 21 Jun 2000 00:55:00 +0100
[EMAIL PROTECTED] (H H Chau) writes:
> Um ... In my linux box, I don't have unlink(1). I know nothing
> about *BSD. Strange enough, there are unlink(1) in both SunOS and
> IRIX. Of course, what does "most" embrace is subject to individual's
> interpretation.
link(1) and unlink(1) are in the Single Unix Specification. I'm not sure
why, or wtf they are for. (Do we have anyone on the appropriate Austin
Group mailing list here? If this was comp.os.linux.development.system,
we would have. Crossposted accordingly.)
--
> ... knowing the alignment of Orcs in AD&D.
Doubleword.
--- David Jacoby and Greg Andrews in the Monastery
------------------------------
From: Tom Roberts <[EMAIL PROTECTED]>
Subject: QUERY: swap to/from a char device?
Date: Wed, 21 Jun 2000 16:49:37 -0500
The Linux kernel can swap to/from both a block device (the usual
case such as a disk partition) and a file. Can this file be a char
device?
I have the choice of writing either a char or block driver, but am
much more familiar with char drivers. I have no desire to mount a
filesystem on this device, only using it for swapping. If a char
device can indeed be used (as I suspect), will there be any swap
performance difference between a block and a char device driver?
Tom Roberts [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
******************************
