[29743] in Perl-Users-Digest
Perl-Users Digest, Issue: 987 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 29 14:09:44 2007
Date: Mon, 29 Oct 2007 11:09:05 -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 Mon, 29 Oct 2007 Volume: 11 Number: 987
Today's topics:
Re: configurable variables in own file? <bik.mido@tiscalinet.it>
Re: From "The Camel Book", Ch. 16 (IPC) <AaronJSherman@gmail.com>
how to close a stalled file descriptor? <eponymousalias@yahoo.com>
Re: IPC::Open3 and the error filehandle <peter@makholm.net>
Re: packing a C structure <haairam@gmail.com>
Re: PID of exec hendedav@gmail.com
Re: PID of exec hendedav@gmail.com
Re: PID of exec xhoster@gmail.com
Re: PID of exec hendedav@gmail.com
Re: TeX pestilence <tim@birdsnest.maths.tcd.ie>
timing out slow operations <eponymousalias@yahoo.com>
Re: timing out slow operations <elvis-85473@notatla.org.uk>
Re: timing out slow operations <jgibson@mail.arc.nasa.gov>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 29 Oct 2007 11:31:01 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: configurable variables in own file?
Message-Id: <ccdbi35pdqv7o2b5ssk1o3dlocasiqq0i4@4ax.com>
On Sun, 28 Oct 2007 19:12:58 -0500, Ted Zlatanov <tzz@lifelogs.com>
wrote:
>MD> That is not what was being proposed. I think both the OP and x had in
>MD> mind a situation in which users have some Perl experience a priori.
>
>The OP never mentioned Perl experience about his users; he wanted a
>module to avoid CPAN and to include some configuration data plus code.
^^^^
^^^^
>His users were supposed to *edit* but not necessarily *know* Perl. In
Well, if they are supposed to edit more or less generic code (IIRC he
talked about some subs) as opposed to simple data which can be
considered a very restricted subset of the language, the it's
difficult to suppose they have *no* experience at all. (However he did
not mention code in the very first post...)
>fact you were as surprised as me that he expected them to edit Perl when
>they couldn't handle CPAN installs.
I was, and I am! :)
>xhoster used himself as the measuring stick several times, but I did not
>see an implication that his users would know Perl. I think assuming the
>users will know (or care to learn) Perl, if that's what xhoster and the
>OP did, is a fundamental problem with an all-Perl configuration system.
>If you make that assumption it's easy to justify such a system.
Anyway it's largely a problem of OP's and I think it is moot to lose
time continuing to argue each other when basically we all agree, after
all!
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Mon, 29 Oct 2007 09:38:57 -0700
From: Aaron Sherman <AaronJSherman@gmail.com>
Subject: Re: From "The Camel Book", Ch. 16 (IPC)
Message-Id: <1193675937.674487.168740@y42g2000hsy.googlegroups.com>
On Oct 25, 7:03 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Yes: I should have tested before posting :). It seems that at least
> SIGALRM can interrupt a blocking flock.
Side note: in researching this topic, I found this text in perlipc:
"In future Perl's signal mechanism may be
changed to avoid this - perhaps by simply disallowing %SIG handlers
on signals of that type. Until then the work-round is not to set a
%SIG handler on those signals. (Which signals they are is operating
system dependent.)"
Someone really should copyedit that text. It's really not readable as-
is.
------------------------------
Date: Mon, 29 Oct 2007 02:52:56 -0700
From: Glenn <eponymousalias@yahoo.com>
Subject: how to close a stalled file descriptor?
Message-Id: <1193651576.349679.237890@y27g2000pre.googlegroups.com>
I'm having trouble closing a file descriptor on a stalled named pipe.
To unblock myself if the write takes too long because the pipe is full
and there is no reader on the other end of the pipe, I put in place
a signal handler. But if the signal handler is invoked and I regain
control, on any subsequent attempt to close the file descriptor,
it stalls again! How do I force the file descriptor to close so I
don't have an infinite buildup of file descriptors in my process,
if I want to continue operating? Even a simple "die" or "exit"
won't work because it tries to close the file descriptor and hangs!
------------------------------
Date: Mon, 29 Oct 2007 10:48:40 +0000
From: Peter Makholm <peter@makholm.net>
Subject: Re: IPC::Open3 and the error filehandle
Message-Id: <87lk9mi4c7.fsf@hacking.dk>
Ben Morrow <ben@morrow.me.uk> writes:
> Better would be to replace ERRFH iff it is undef-but-an-lvalue.
> Something like
Thanks to both of you. I'll add something along the lines of this to
our internal code library.
//Makholm
------------------------------
Date: Mon, 29 Oct 2007 04:04:19 -0700
From: rams <haairam@gmail.com>
Subject: Re: packing a C structure
Message-Id: <1193655859.637895.253890@v29g2000prd.googlegroups.com>
On Oct 26, 10:37 pm, "jl_p...@hotmail.com" <jl_p...@hotmail.com>
wrote:
> On Oct 25, 10:57 pm, haai...@gmail.com wrote:
>
>
>
>
>
> > hi ,,,
>
> > iam trying to pack a C structure to send via socket..i would like to
> > know how to frame the template for the C structure..
>
> > this is my structure
>
> > typedef struct buffer_t {
> > uint32_t a;
> > char b[16];
> > uint32_t c;
> > uint32_t d;
> > char e[6];
> > char f[8];
>
> > } buffer_t;
>
> > kindly suggest me the format for the pack function call..this will
> > help me to solve my issue...
>
> Hi,
>
> I have the impression that what you want is to pack values in Perl
> into a binary string of data that matches how a C program would do it.
>
> If I'm right, this might work:
>
> my $stringToSend = pack('I c16 I I c6 c8',
> <YOUR PERL VARIABLES GO HERE>);
>
> However, it's quite likely that the C program packs the data in a
> way so that they are properly byte-aligned. If that's the case, the
> above pack string may not work, and you'd probably have better luck
> with the following pack string that inserts padding in the proper
> places:
>
> my $stringToSend = pack('I c16 x![I] I I c6 c8 x![I]',
> <YOUR PERL VARIABLES GO HERE>);
>
> Out of curiosity, when you declare b as a char array of 16 elements
> is that because you're sending over 16 separate char values, or are
> you sending one null-terminated string that can be a maximum of 15
> characters long?
>
> If your intention is to use b[16] as a single string (holding a
> maximum of 15 characters), you probably want to replace "c16" in the
> above pack strings to "Z16" (you may also want to replace "c6" and
> "c8" with "Z6" and "Z8"). That way, instead of sending over 33
> separate variables (that is, three ints plus 30 characters), you'd be
> sending over six separate variables (that is, three ints plus three
> strings).
>
> So if it's the case that you want to send over three ints and three
> strings, you might use code like this:
>
> my $a = 1;
> my $b = "Title of book";
> my $c = 3;
> my $d = 4;
> my $e = "March";
> my $f = "Sunday";
> my $stringToSend = pack('I Z16 x![I] I I Z6 Z8 x![I]',
> $a, $b, $c, $d, $e, $f);
>
> Unfortunately, there's no real way to know what the proper pack
> string should be unless you analyze the binary structure that your C
> program writes out (or if can find one, reads in). But it's likely
> that one of pack strings I gave you (or a variant) will work.
>
> I hope this helps. Perl's pack() function is very powerful and
> useful when dealing with C structures written out to disk.
>
> -- Jean-Luc- Hide quoted text -
>
> - Show quoted text -
hi ,,
Thanks for ur help....when i used the format specified by you i
observed a strange behaviour..i have given $a value as 271 ans i
expect that the data while sending through socket would be 00 00 01 0f
that is hex value(271) 0x010F but what i saw as a output of my socket
is data as 32 37 31...since i tried with L option as well both are
giving the same result.how to send that value as a hex itself..
for a variable $b i need to send 16 characters iam wondering during
packing what will happen to the Null Character of the string.
kindly provide a feedback.
Regards
Rams
------------------------------
Date: Mon, 29 Oct 2007 12:48:10 -0000
From: hendedav@gmail.com
Subject: Re: PID of exec
Message-Id: <1193662090.784644.264310@o3g2000hsb.googlegroups.com>
On Oct 27, 12:07 am, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth hende...@gmail.com:
>
>
>
> > On Oct 26, 4:26 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > > Quoth hende...@gmail.com:
>
> > > > [snip] Also, this
> > > > script seems to be generating zombies. Anyone have ideas on how to
> > > > clear that up? I was hoping that the "local $SIG{CHLD} = "IGNORE";"
> > > > line would do the trick (as it stated in the perldoc's), but I guess
> > > > not.
>
> > > Setting SIGCHLD to IGNORE to clean up zombies is non-portable. Possibly
> > > your system doesn't have this behaviour: you will need to wait for your
> > > children yourself.
>
> > Ben, thanks for the info on not being portable. I would actually like
> > this code to work on Linux and Windows (I know I will have to make
> > changes to the way the PIDs are interacted with, but that will come
> > down the road). The problem with waiting for the child to complete,
> > is that the client will timeout. This is why I am trying to fork a
> > child process from the parent, so it can complete and the browser can
> > be doing other things.
>
> Using
>
> use POSIX qw/:sys_wait_h/;
>
> $SIG{CHLD} = sub { 1 while waitpid(-1, WNOHANG) > 0 };
>
> should reap any children that exit before you do under any Unix (IIRC
> perl handles the broken SysV non-reinstalled signal handlers itself
> nowadays). Under Win32, fork is faked: it doesn't actually create a new
> process, just a new thread in the perl process. exec from a
> pseudo-process will spawn(3) the exec'd child and leave the thread
> waiting for it exit, so 'zombies' will still accumulate but they will
> just be unjoined threads inside the perl process, not anything visible
> to the system, and will be cleaned up when perl exits. (Annoyingly it
> appears to me that the Win32 fork emulation *doesn't* send SIGCHLD when
> a pseudechild exits... can anyone on Win32 confirm this?)
>
> In any case, under both Unix and Win32, once the parent has exitted the
> system takes responsibility for cleaning up after the child. Under Unix,
> init(8) cleans up for you, under Win32 processes (real OS processes, not
> perl's pseudo-processes) don't have parents so they don't ever turn into
> zombies.
>
> [You mention Linux: Linux is a system which *does* provide the SIGCHLD =
> IGNORE functionality, so if that's what you're testing under you have
> some other problem.]
>
> Ben
I am testing under GNU/Linux (Debian 3.1 Sarge). And I think I have
confirmed that a zombie gets created for each call to this script. I
put a system command in the "if" and "elsif" sections that writes to a
debug.txt file everytime one of them is accessed. I end up with 19
lines in the text file and 19 zombies. While the "polling" to that
script is taking place, I run ps several times and can see the zombie
count growing. I tried adding the lines that you mentioned, but it
still didn't help. I am not sure what to do at this point.
Thanks,
Dave
------------------------------
Date: Mon, 29 Oct 2007 12:57:46 -0000
From: hendedav@gmail.com
Subject: Re: PID of exec
Message-Id: <1193662666.216258.53810@k79g2000hse.googlegroups.com>
On Oct 27, 1:07 pm, Juha Laiho <Juha.La...@iki.fi> wrote:
> hende...@gmail.com said:
>
> >I read another post that said after running the exec statment, it is
> >a highly recommended to use an "exit();" statement. Does this sound
> >correct?
>
> It's a good safety belt -- it's for the case where the exec() call fails.
>
> If that happens, the child will continue running whatever code there is
> beyond the child branch of the fork - which definitely is something that
> was never intended to happen. In addition to exit(), you might want to
> log an error somewhere, and it might be good idea to exit() with
> a nonzero status, so your parent process could also catch and log the
> failure situation.
> --
> Wolf a.k.a. Juha Laiho Espoo, Finland
> (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
> PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
> "...cancel my subscription to the resurrection!" (Jim Morrison)
Thanks for the tip. I have changed that section of code to:
exec("/tmp/test.sh");
&write2Log("$gbl_logsDir/$gbl_reErrLog", "Could not execute the script
file\ndue to the following error:\n\n$! [script, body]");
exit 1;
the write2log routine is part of a module i have written that
basically writes whatever is passed to a log file. Let me know of any
other tips that would be helpful.
Thanks,
Dave
------------------------------
Date: 29 Oct 2007 16:12:41 GMT
From: xhoster@gmail.com
Subject: Re: PID of exec
Message-Id: <20071029121242.627$l1@newsreader.com>
hendedav@gmail.com wrote:
>
> I am testing under GNU/Linux (Debian 3.1 Sarge). And I think I have
> confirmed that a zombie gets created for each call to this script. I
> put a system command in the "if" and "elsif" sections that writes to a
> debug.txt file everytime one of them is accessed. I end up with 19
> lines in the text file and 19 zombies. While the "polling" to that
> script is taking place, I run ps several times and can see the zombie
> count growing.
I don't see how this can have anything to do with the code you showed
us. Maybe it is something about your web-server that is causing the
zombies.
> I tried adding the lines that you mentioned, but it
> still didn't help. I am not sure what to do at this point.
Create a do-nothing hello world script and see if that leaves zombies.
Break your existing code into two different scripts (one for the if block
one for the else block) and see what one, if any, leaves zombies.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Mon, 29 Oct 2007 17:12:44 -0000
From: hendedav@gmail.com
Subject: Re: PID of exec
Message-Id: <1193677964.224609.104680@19g2000hsx.googlegroups.com>
On Oct 29, 12:12 pm, xhos...@gmail.com wrote:
> hende...@gmail.com wrote:
>
> > I am testing under GNU/Linux (Debian 3.1 Sarge). And I think I have
> > confirmed that a zombie gets created for each call to this script. I
> > put a system command in the "if" and "elsif" sections that writes to a
> > debug.txt file everytime one of them is accessed. I end up with 19
> > lines in the text file and 19 zombies. While the "polling" to that
> > script is taking place, I run ps several times and can see the zombie
> > count growing.
>
> I don't see how this can have anything to do with the code you showed
> us. Maybe it is something about your web-server that is causing the
> zombies.
>
> > I tried adding the lines that you mentioned, but it
> > still didn't help. I am not sure what to do at this point.
>
> Create a do-nothing hello world script and see if that leaves zombies.
> Break your existing code into two different scripts (one for the if block
> one for the else block) and see what one, if any, leaves zombies.
>
> Xho
>
> --
> --------------------http://NewsReader.Com/--------------------
> The costs of publication of this article were defrayed in part by the
> payment of page charges. This article must therefore be hereby marked
> advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
> this fact.
I created a test.cgi that only printed out a "hello world" string and
I am still getting a very low number of them (1-2) occasionally (the
client will continue to poll until a certain response is received)
when I issue a ps command. Would there be a problem with this script
getting called to frequently? This is obviously a much simpler script
that the one I posted so it has time to completely finish before the
next "poll". Any ideas?
Xho I can still separate the script if you would like (if there isn't
enough information already given).
Thanks,
Dave
------------------------------
Date: Mon, 29 Oct 2007 13:23:48 +0000
From: Timothy Murphy <tim@birdsnest.maths.tcd.ie>
Subject: Re: TeX pestilence
Message-Id: <E9lVi.22870$j7.433201@news.indigo.ie>
David Kastrup wrote:
> But as a programming language, it is a steaming pile of crap. And
> that's not least because it is a team from a blind and a lame
> programming system: only TeX's stomach can _affect_ a variable, but
> only TeX's mouth can _look_ at a variable and make decisions based on
> its values, decisions for which a resulting action again can only be
> done by the blind stomach. Both systems kick in at different points
> of time and different circumstances. And you must not employ the
> stomach in the middle of typesetting a word, or kernings and ligatures
> will break.
I'm amazed that this nonsense appears to have been swallowed
hook, line and sinker by the readers of - or at least contributors to -
this newsgroup.
Ken Thompson said: A program should do one thing, and do it well.
The one thing that TeX does, and does superbly well, is typeset mathematics.
95% of the "problems" with TeX discovered by TeXperts
are not problems at all to anyone except themselves.
TeX and LaTeX is used round the world for the purpose it was designed for
by thousands of people who find it does the job they want perfectly well.
------------------------------
Date: Mon, 29 Oct 2007 01:22:32 -0700
From: Glenn <eponymousalias@yahoo.com>
Subject: timing out slow operations
Message-Id: <1193646152.551129.42090@t8g2000prg.googlegroups.com>
I'm trying to figure out the code segment on page 417 of the
Camel book, 3/e. It says:
use Fcntl ':flock';
eval {
local $SIG{ALRM} = sub { die "alarm clock restart" };
alarm 10; # schedule alarm in 10 seconds
eval {
flock(FH, LOCK_EX) # a blocking, exclusive lock
or die "can't flock: $!";
};
alarm 0; # cancel the alarm
};
alarm 0; # race condition protection
die if $@ && $@ !~ /alarm clock restart/; # reraise
and then the text says:
The second "alarm 0" is provided in case the signal comes in after
running the flock but before getting to the first "alarm 0".
Without the second alarm, you would risk a tiny race condition ...
This last bit sounds like nonsense to me. If the alarm comes in at
that point, then it comes in, gets processed, and the alarm is turned
off already by that processing -- i.e., by the alarm expiration, not
by an explicit "alarm 0" call. Alarms don't re-start themselves upon
expiration, so there's no need to turn it off again. Am I missing
something?
If there were to be a race condition at all, it would be if you
somehow
managed to escape from the outer eval{} while the alarm had not yet
expired, without turning off the alarm. Then there would be no alarm
handler in place, and your code would die when the alarm finally does
expire. But trying to turn off the alarm outside of the outer eval{}
would still leave a tiny space between the end of that eval{} and the
last
"alarm 0" during which the alarm might come in -- meaning the race is
not solved with this second "alarm 0". But I don't even see any way
out of the outer eval{} that doesn't involve the alarm already being
off, either because of the first "alarm 0" or because the alarm
expired
and therefore got turned off before you executed the first "alarm 0".
------------------------------
Date: 29 Oct 2007 09:35:27 GMT
From: all mail refused <elvis-85473@notatla.org.uk>
Subject: Re: timing out slow operations
Message-Id: <slrnfiba74.vp1.elvis-85473@notatla.org.uk>
On 2007-10-29, Glenn <eponymousalias@yahoo.com> wrote:
> I'm trying to figure out the code segment on page 417 of the
> Camel book, 3/e. It says:
> alarm 0; # cancel the alarm
> };
> alarm 0; # race condition protection
> die if $@ && $@ !~ /alarm clock restart/; # reraise
>
> and then the text says:
>
> The second "alarm 0" is provided in case the signal comes in after
> running the flock but before getting to the first "alarm 0".
> Without the second alarm, you would risk a tiny race condition ...
Someone asked this just the other day - you should be able to find the
discussion in the archives.
--
Elvis Notargiacomo master AT barefaced DOT cheek
http://www.notatla.org.uk/goen/
------------------------------
Date: Mon, 29 Oct 2007 10:21:49 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: timing out slow operations
Message-Id: <291020071021493215%jgibson@mail.arc.nasa.gov>
In article <1193646152.551129.42090@t8g2000prg.googlegroups.com>, Glenn
<eponymousalias@yahoo.com> wrote:
> I'm trying to figure out the code segment on page 417 of the
> Camel book, 3/e. It says:
>
> use Fcntl ':flock';
> eval {
> local $SIG{ALRM} = sub { die "alarm clock restart" };
> alarm 10; # schedule alarm in 10 seconds
> eval {
> flock(FH, LOCK_EX) # a blocking, exclusive lock
> or die "can't flock: $!";
> };
> alarm 0; # cancel the alarm
> };
> alarm 0; # race condition protection
> die if $@ && $@ !~ /alarm clock restart/; # reraise
>
> and then the text says:
>
> The second "alarm 0" is provided in case the signal comes in after
> running the flock but before getting to the first "alarm 0".
> Without the second alarm, you would risk a tiny race condition ...
>
> This last bit sounds like nonsense to me. If the alarm comes in at
> that point, then it comes in, gets processed, and the alarm is turned
> off already by that processing -- i.e., by the alarm expiration, not
> by an explicit "alarm 0" call. Alarms don't re-start themselves upon
> expiration, so there's no need to turn it off again. Am I missing
> something?
I believe the issue is a potential signal that is not the alarm signal
occurring after the inner eval but before the subsequent alarm 0. It
seems unlikely, but that is how one makes code bomb-proof: expect the
improbable and deal with it. After all, it doesn't hurt much to do an
extra alarm 0.
> If there were to be a race condition at all, it would be if you
> somehow
> managed to escape from the outer eval{} while the alarm had not yet
> expired, without turning off the alarm. Then there would be no alarm
> handler in place, and your code would die when the alarm finally does
> expire. But trying to turn off the alarm outside of the outer eval{}
> would still leave a tiny space between the end of that eval{} and the
> last
> "alarm 0" during which the alarm might come in -- meaning the race is
> not solved with this second "alarm 0". But I don't even see any way
> out of the outer eval{} that doesn't involve the alarm already being
> off, either because of the first "alarm 0" or because the alarm
> expired
> and therefore got turned off before you executed the first "alarm 0".
>
I suppose you should set up an alarm handler before going into the
outer eval.
--
Jim Gibson
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
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 V11 Issue 987
**************************************
