2012/1/18 Peter Vereshagin :
> Just don't 'use threads;', that's all :)
>
> The only exception is the cygwin's use of native ms-windows threads behind its
> forks emulation, including cygwin's perl.
Unless things have changed since I last used it, cygwin uses real
processes for forks. It's Active
Hello.
2011/12/19 18:31:53 +1100 Toby Wintermute => To London.pm
Perl M[ou]ngers :
TW> > 2011/12/16 12:38:16 +1100 Toby Wintermute => To
London.pm Perl M[ou]ngers :
TW> > TW> > (i)Threaded perl5 ( 'use threads' ) doesn't seem to be recommended
for
TW> > TW> > production environments.
TW> > TW
On Dec 19, 2011, at 9:50 AM, Yitzchak Scott-Thoennes wrote:
> On Sun, Dec 18, 2011 at 11:31 PM, Toby Wintermute wrote:
>> 2011/12/16 Peter Vereshagin :
>>> 2011/12/16 12:38:16 +1100 Toby Wintermute => To
>>> London.pm Perl M[ou]ngers :
>>> TW> > (i)Threaded perl5 ( 'use threads' ) doesn't seem t
On Fri, Dec 16, 2011 at 12:38:16PM +1100, Toby Wintermute wrote:
> 2011/12/16 Peter Vereshagin :
> > (i)Threaded perl5 ( 'use threads' ) doesn't seem to be recommended for
> > production environments.
>
> I know it certainly wasn't recommended back in the days of 5.6 or 5.8,
> but I thought thing
On 18 Dec 2011, at 21:06, Yitzchak Scott-Thoennes wrote:
> On Sat, Dec 17, 2011 at 11:43 PM, Dave Hodgkinson wrote:
>> On 18 Dec 2011, at 02:57, Yitzchak Scott-Thoennes wrote:
>>> If all you need is to return results of a discrete bit of work to the
>>> parent, Parallel::ForkManager makes it tri
On 18 Dec 2011, at 14:48, Ruud H.G. van Tol wrote:
> On 2011-12-18 08:43, Dave Hodgkinson wrote:
>> On 18 Dec 2011, at 02:57, Yitzchak Scott-Thoennes wrote:
>
>>> If all you need is to return results of a discrete bit of work to the
>>> parent, Parallel::ForkManager makes it trivial.
>>
>> And
On Sun, Dec 18, 2011 at 11:31 PM, Toby Wintermute wrote:
> 2011/12/16 Peter Vereshagin :
>> 2011/12/16 12:38:16 +1100 Toby Wintermute => To
>> London.pm Perl M[ou]ngers :
>> TW> > (i)Threaded perl5 ( 'use threads' ) doesn't seem to be recommended for
>> TW> > production environments.
>> TW>
>> T
2011/12/16 Peter Vereshagin :
> Hello.
>
> 2011/12/16 12:38:16 +1100 Toby Wintermute => To
> London.pm Perl M[ou]ngers :
> TW> > (i)Threaded perl5 ( 'use threads' ) doesn't seem to be recommended for
> TW> > production environments.
> TW>
> TW> I know it certainly wasn't recommended back in the d
On Sat, Dec 17, 2011 at 11:43 PM, Dave Hodgkinson wrote:
> On 18 Dec 2011, at 02:57, Yitzchak Scott-Thoennes wrote:
>> If all you need is to return results of a discrete bit of work to the
>> parent, Parallel::ForkManager makes it trivial.
>
> And the best way to return those results...?
$pfm->fi
On 2011-12-18 08:43, Dave Hodgkinson wrote:
On 18 Dec 2011, at 02:57, Yitzchak Scott-Thoennes wrote:
If all you need is to return results of a discrete bit of work to the
parent, Parallel::ForkManager makes it trivial.
And the best way to return those results...?
Unless the exit code is in
On 18 Dec 2011, at 02:57, Yitzchak Scott-Thoennes wrote:
> On Thu, Dec 15, 2011 at 5:38 PM, Toby Wintermute wrote:
>> Which is the reason I was using threads - it's easy to do IPC between
>> them by sharing access to some data structures.
>> Whereas with forking you need to set up pipes, posix s
On Thu, Dec 15, 2011 at 5:38 PM, Toby Wintermute wrote:
> Which is the reason I was using threads - it's easy to do IPC between
> them by sharing access to some data structures.
> Whereas with forking you need to set up pipes, posix shared memory,
> sockets, or some other means.
>
> In the end, I
Hello.
2011/12/16 12:38:16 +1100 Toby Wintermute => To London.pm
Perl M[ou]ngers :
TW> > (i)Threaded perl5 ( 'use threads' ) doesn't seem to be recommended for
TW> > production environments.
TW>
TW> I know it certainly wasn't recommended back in the days of 5.6 or 5.8,
TW> but I thought things
2011/12/16 Peter Vereshagin :
> Hello.
>
> 2011/12/14 12:16:04 +1100 Toby Wintermute => To
> London.pm Perl M[ou]ngers :
> TW> I'm hitting some really odd behaviour, infrequently, with libwww and
> TW> mechanize under a highly-threaded Perl.
>
> TW> Error rates initially increase with the number
Hello.
2011/12/14 12:16:04 +1100 Toby Wintermute => To London.pm
Perl M[ou]ngers :
TW> I'm hitting some really odd behaviour, infrequently, with libwww and
TW> mechanize under a highly-threaded Perl.
TW> Error rates initially increase with the number of simultaneous
TW> threads, but seem to top
Does looking at the response headers or content of the 404s show
anything of interest?
If you have control of the webserver, on a 404, verify that the
request looks correct, too.
On Tuesday, December 13, 2011 at 08:16:04 PM, Toby Wintermute wrote:
> Hi,
Hi
> The 404 errors are reported on the distant webserver as well, for URLs
> that are definitely not 404. (as the identical URL is being requested
> successfully many times in the same period).
>
The server should know
>
> --
>
> Message: 1
> Date: Wed, 14 Dec 2011 08:44:37 +
> From: Leo Lapworth
> Subject: Re: Perl threads and libwww wierdness
> To: "London.pm Perl M[ou]ngers"
> Message-ID:
>
On 14 December 2011 19:44, Leo Lapworth wrote:
> I still think it's your webserver
See below..
> On 14 December 2011 01:16, Toby Wintermute wrote:
>> I'm hitting some really odd behaviour, infrequently, with libwww and
>> mechanize under a highly-threaded Perl.
>
>> I have encountered a sit
I still think it's your webserver
On 14 December 2011 01:16, Toby Wintermute wrote:
> I'm hitting some really odd behaviour, infrequently, with libwww and
> mechanize under a highly-threaded Perl.
> I have encountered a situation where I see unusual 404 errors - in
> between 0.03% to 0.10% o
On 14 December 2011 12:16, Toby Wintermute wrote:
> Hi,
> I'm hitting some really odd behaviour, infrequently, with libwww and
> mechanize under a highly-threaded Perl.
Worth noting - I'm pretty sure LWP is all pure-perl, but mechanize
calls some XS libraries - HTML::Parser, PullParser and TokeP
Hi,
I'm hitting some really odd behaviour, infrequently, with libwww and
mechanize under a highly-threaded Perl.
Can I get a quick check to see if what I'm doing is known to work
reliably for you?
I have encountered a situation where I see unusual 404 errors - in
between 0.03% to 0.10% of request
22 matches
Mail list logo
