#perl
27 October 2007
Total 23 pages. You are browsing page 2/23.
First :: Prev :: [1] [2] [3] [4] [5] [...] :: Next :: Last
01:55 <****> can't ReuseAddr or whatever do soemething?
01:55 * dazjorz checks apache.org
01:56 <****> anno-: I can't seem to do that
01:56 <****> anno-: is there a way to test for an overloaded %{}? I'm still mistified as to why tied() returns undef, and ref() returns "HASH" on something that's apparently got code in it
01:56 <****> no access to the sockets (handles)?
01:57 <****> StoneToad: reftype from Scalar::Util ?
01:57 <****> how are you calling tied?
01:57 <****> StoneToad: what's to say the hash is what's tied? why not one of the data structures it contains?
01:57 <****> no
01:57 <****> if i wanna use mod_perl2, is it better to use unix?
01:57 <****> overload::Overloaded will tell you if something is overloaded
01:57 <****> Caelum: no just normal ref()
01:58 <****> Somni: well, I picked a random element, I'll try all of them this time
01:58 <****> thanks, somni (was looking for that)
01:58 <****> can you tie hash keys?
01:58 <****> no, only hashes
01:58 <****> keys? no
01:58 <****> no, you can tie hash values though
01:58 <****> rather, you can take references to tied variables, and the tie remains intact
01:58 <****> dngor: So there's no way to kill these sockets, even if the program owning them is still running? (All connections that are still open at the moment I shutdown, go into TIME_WAIT)
01:58 <****> lalalabsd: mod_perl2 works fine on windows. But only the worker mpm is available, so all your code and any modules you use must be thread-safe
01:59 <****> dazjorz: If I knew a way to avoid it, I would make the code not do it.
01:59 <****> is it going to be fixed later?
02:00 <****> lalalabsd: what is going to be fixed?
02:00 <****> the only the working mpm is available
02:00 <****> dngor: What advantages does it have when open client sockets go into TIME_WAIT?
02:00 <****> why only the working mpm is available?
02:01 <****> lalalabsd: because windows has no fork, so you can't use the prefork mpm
02:01 <****> It only makes me unable to use the ports until the kernel kills the sockets
02:01 <****> oh
02:02 <****> who wants a non-working mpm anyway
02:03 <****> dazjorz: It's part of TCP. Read about it.
02:10 <****> dngor: I'm reading, TIME_WAIT seems like a handy thing if you're looking at duplicate packets, but I wonder what the MLS on my system would be
02:10 <****> I guess it'd be about half a minute or so.
02:12 <****> I'm surprised TCP doesn't have some sort of protection to prevent a new program bound to that IP:port from parsing an old packet that was supposed to be received by an older program using that port (except for this TIME_WAIT protection, of course)
02:13 <****> If I remember correctly, TCP carries so much in each packets' header, it wouldn't be that hard to put some protection in there too
02:13 <****> your local TCP stack might have such protection
02:13 <****> but TCP itself doesn't mandate process handling
02:14 <****> Well, if my local TCP stack has protection against it, why would it need TIME_WAIT next to that?
02:15 <****> because it might not, and because TCP requires shutdown sockets go through a TIME_WAIT state
02:17 <****> oh it's Somni!
02:17 <****> Somni: is it also the TCP stack that puts sockets like that into TIME_WAIT mode?
02:18 <****> the TCP stack is an implementation of the TCP protocol, so yes
02:18 <****> Somni: The TCP stack knows of itself it has protection against "zombie" packets, so it knows it can use a TIME_WAIT of a few seconds...
02:18 <****> is there a way to specify a connect timeout in LWP?
02:18 <****> and if it doesn't know about any protection, it can still use the full 240 seconds TIME_WAIT (as I read its default time is 240 seconds)
02:19 <****>timeout seems to only affect HTTP et all timeouts
02:19 <****> dazjorz: you seem abnormally fixated on my statement that the TCP stack might have some protection here
02:20 <****> Somni: Yeah, I am
02:20 <****> MooingLemur: what's the difference between a connect timeout and HTTP et al timeouts?
02:20 <****> Do arrays have internal pointers? ie if I have a (foreach) loop in a loop, and the inner loop uses the same variable as the outer, will I get conflicts when I parse it?
02:21 <****> dazjorz: if we all admitted the wait state was superfluous, would it help?
02:21 <****> the same source list, not the same iterator variable
02:21 <****> Somni: If such a protection exists, I'm quite sure somebody would put it into Linux' TCP stack sooner or later, and at that moment, TIME_WAIT would no longer be required on Linux system
02:21 <****> Somni: one is a connect() timeout. the other is after an HTTP request was sent, but before a reply
02:21 <****> eval: @x = qw(foo bar baz); foreach my $outer (@x) { foreach my $inner (@x) { print "$outer $inner " } }
02:21 <****> Somni: foo foo foo bar foo baz bar foo bar bar bar baz baz foo baz bar baz baz ''
02:21 <****> _codepoet_: when in doubt, try it
02:22 <****> dazjorz: and yet, it's not, so either it doesn't, or the TIME_WAIT state is required, and required for a minimum length
02:22 <****> dazjorz: what is discussing it going to accomplish?
02:22 <****> anno-: Well that depends, if one of the people who admits it's superfluous is in the development team of the Linux kernel and is able to implement this protection Somni and I were talking about, it'd help, yeah
02:23 <****> dazjorz: you are unhinged
02:23 <****> TIME_WAIT is a fact, best get used to it
02:24 <****> Somni: We might come to agree about this protection and TIME_WAIT, and maybe bugreport a wish against the Linux kernel
02:24 <****> Hmm
02:25 <****> Well it's a fact in the TCP RFC, and since RFC still stands for "Request For Comments" iirc, we've got a comment here
02:25 <****> MooingLemur: well, the timeout value is passed on down the line, from LWP::UserAgent down to IO::Socket::INET, so whatever perceived lack of timeout you're seeing on the connect is either a misunderstanding or an old version of something
02:26 <****> RFC 793 was written in September 1981, and I don't see any link to an RFC that deprecates this one, so maybe it's time to ask the University of Southern California which wrote this one, to write a new one
02:27 <****> dazjorz: do you have a point?
02:28 <****> Somni: my point is that TCP should have protection against packets which come in too late, the second point is that due to the first point, we do not seem to need TIME_WAIT anymore
02:28 <****> dazjorz: yea, #Perl can't help you with that, good luck
02:29 <****> I don't know how changes to RFC's go over time, but I've noticed the IRC RFC seems to be outdated too, and that one comes from 1993, that's twelve years later than the TCP RFC
02:29 <****> But you're right, I'll go somewhere else, I'll find a place
02:29 <****> :)
02:29 <****> although, while you're on your fruitless crusade to see TIME_WAIT removed from the specification, you might consider how to distinguish between a packet received for an old process and one received for the new
02:30 <****> hah what?
02:31 <****> Somni: Well that's the protection we're talking about, there must be *some* way (PIDs are recycled, but if you have fifty thousand, the chances are small the same one will be used within five minutes, or something is very wrong)
02:31 <****> not everything with a TCP stack has PIDs, or processes
02:32 <****> dazjorz: relying on PIDs is not a good idea. OpenBSD (for example) randomizes PIDs, so you could have two processes that get the same PID one after another. unlikely, but it could happen.
02:32 <****> so not everything will have this built in protection, indeed, but at least Linux is able to implement it, and so are other OSes like BSD and Windows
02:32 <****> hmm
02:33 <****> pravus: Yeah that doesn't simplify it
02:34 <****> you might also want to learn about TCP implementations now, and what kind of protections they do have
02:38 <****> Brutally obvious newb question: What's the most standard way to get a Perl shell running? I have ActivePerl.
02:38 <****> sup hackers..
02:38 <****> what do you mean by "perl shell"?
02:38 <****> (as in REPL, nothing special needed)
02:38 <****> perl -MCPAN -e shell
02:38 <****> (ab)use the debugger
02:39 <****> Perl shell? ugh...
02:39 <****> perl -d -e0
02:39 <****> Like irb, wish, or what you come up when you run python without an arg
02:39 <****>"
02:39 <****> Ugh, this is a TIMTOWTDI moment :P
02:39 <****> welcome to Perl
02:42 <****> no-one mentioned Devel::REPL yet
02:42 <****> I was about!
02:42 <****> i was going to, but i don't know if ActiveState has it
02:42 <****> This built-in debugger seems to be a tricked out REPL, innit?
02:43 <****> doesn't seem to be in the AS repo or UWinnipeg though
Total 23 pages. You are browsing page 2/23.
First :: Prev :: [1] [2] [3] [4] [5] [...] :: Next :: Last