[26143] in Perl-Users-Digest
Perl-Users Digest, Issue: 8334 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 18 21:05:12 2005
Date: Thu, 18 Aug 2005 18:05:03 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 18 Aug 2005 Volume: 10 Number: 8334
Today's topics:
ftp client to send data using a certain network interfa <noaddress@nodomain.com>
Re: ftp client to send data using a certain network int <ddunham@redwood.taos.com>
Re: How to detect a dead parent? chris-usenet@roaima.co.uk
Re: How to detect a dead parent? (Anno Siegel)
Re: Organizing data for readability and efficiency xhoster@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 18 Aug 2005 17:58:56 -0500
From: "Tambaa Hapa" <noaddress@nodomain.com>
Subject: ftp client to send data using a certain network interface
Message-Id: <de33rg$j0u$1@home.itg.ti.com>
Anyone know of an ftp client or a way to write one in Perl that will send
data to another host using a specific network interface. I would like to
test the throughput of our backup network and hence would like to force the
client to use a specific network interface card.
This is on Solaris.
Thanks in advance,
TH
------------------------------
Date: Thu, 18 Aug 2005 23:30:03 GMT
From: Darren Dunham <ddunham@redwood.taos.com>
Subject: Re: ftp client to send data using a certain network interface
Message-Id: <%R8Ne.54$Ux3.18@newssvr21.news.prodigy.com>
In comp.unix.solaris Tambaa Hapa <noaddress@nodomain.com> wrote:
> Anyone know of an ftp client or a way to write one in Perl that will send
> data to another host using a specific network interface. I would like to
> test the throughput of our backup network and hence would like to force the
> client to use a specific network interface card.
Are the two interfaces on the same sub-network? This is usually most
easily done by having the routing table correct on the host, then using
the desired interface on the remote machine as the host target.
How does the backup software select the correct interface?
--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
------------------------------
Date: Thu, 18 Aug 2005 22:51:29 +0100
From: chris-usenet@roaima.co.uk
Subject: Re: How to detect a dead parent?
Message-Id: <1gcft2-bl2.ln1@news.roaima.co.uk>
Mark Mackey <markm@chiark.greenend.org.uk> wrote:
> and the children drop privileges, so the children aren't priviledged to
> signal the parent (even kill 0, which doesn't actually send a signal.
You're talking UNIX/Linux?
It is possible to use kill 0 to determine whether a process exists
or not. You simply have to differentiate between a "No such process"
error and a "Permission denied" error. (The latter indicates that the
PID exists but you don't have permission to singal it.)
Process exists but is not owned by self:
$ perl -e 'kill 0, 1; print "Status ", $! +0, ": $!\n"'
Status 1: Operation not permitted
Process does not exist:
$ perl -e 'kill 0, 111; print "Status ", $! +0, ": $!\n"'
Status 3: No such process
Process exists and is owned by self:
$ sleep 60 &
[1] 2669
$ perl -e 'kill 0, 2669; print "Status ", $! +0, ": $!\n"'
Status 0:
Chris
------------------------------
Date: 18 Aug 2005 22:17:09 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: How to detect a dead parent?
Message-Id: <de31d5$9ui$1@mamenchi.zrz.TU-Berlin.DE>
Mark Mackey <markm@chiark.greenend.org.uk> wrote in comp.lang.perl.misc:
> Hi all.
>
> I've got a daemon script which forks off several children which go and
> do funky things with sockets and the like. I need to make sure that the
> children are killed when the parent dies, so I've installed signal
> handlers in the parent which kill HUP => -$$; when the parent exits or
> receives a signal.
>
> However, under some circumstances the parent dies (if it's kill -9'ed,
> for example) without signalling the children, which then live a happy
> existence not knowing that they should be dead. This is a problem.
>
> So, the question is, how can a child detect that its parent is dead? I
> tried using getppid() to test if the ppid had becore equal to 1 (which
> is what happens after the parent exits), but after frustrating hours of
> debugging I found a web page which pointed out the AFAIK undocumented
> fact that Perl caches the ppid on Linux and so will always return the
> same value in a script. Grrr. I also tried doing a kill 0 => getppid;,
> which works in theory but not in practice because the parent is uid 0
> and the children drop privileges, so the children aren't priviledged to
> signal the parent (even kill 0, which doesn't actually send a signal.
> Double Grrr.)
>
> So, any suggestions? I've run out of ideas that aren't really hacky
> (like faffing around with sockets, or reading /proc directly, or running
> 'ps' and parsing the output, or other horrible things). A way of
> ensuring that the children die directly when the parent does would be even
> better.
Why don't you just keep the parent pid in a variable, or even
use constant PPID => $$;
for the children to use?
use Errno 'EPERM';
if ( kill 0, PPID or $! == EPERM ) {
# parent still alive
}
I think it's EPERM what you get when the process exists but you can't
signal, but haven't checked.
An alternative way to monitor the lifetime of a particular process is
to let it keep a lock on a file. Other processes can test for the
existence of the lock. If the process goes, so does the lock.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 19 Aug 2005 01:01:56 GMT
From: xhoster@gmail.com
Subject: Re: Organizing data for readability and efficiency
Message-Id: <20050818210156.551$cc@newsreader.com>
Mark Seger <Mark.Seger@hp.com> wrote:
> > If you are considering making the choice between arrays and hashes
> > based on the performance of single look-ups into each (rather than by
> > whether the nature of your data best fits an array or best fits a
> > hash), then I say you are engaging in micro-optimization. Perhaps this
> > is the nub of your question, so let me repeat. The difference between
> > array access and hash access is small enough that if you are concerned
> > about it, only actual tests on actual data will be satifactory.
>
> Let me try again, I'm not concerned about the performance of single
> lookups, I'm concerned with at least hundreds of thousands.
A single lookup is contrasted with slices, splice, grep, map, keys, values,
sort, List::Util::first, List::Util::max, List::Util::sum, etc. etc. If
you do single lookups a hundred thousand times, they don't stop being
single lookups.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8334
***************************************
