Perl threads and libwww wierdness

[Toby Wintermute]

2011/12/16 Peter Vereshagin <peter at vereshagin.org>:
> Hello.
>
> 2011/12/16 12:38:16 +1100 Toby Wintermute <tjc at wintrmute.net> => 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 had improved since then..
>
> They did. Perl6 was released and it seems to have threads those can be recommended.
> Perl5 have fork() that 'just works' and seems to be enough.

So, you're saying that threads under perl5 is forever going to be
considered broken and not worth touching then? :(

Why do all the main distros ship a threading-enabled Perl? I note that
Padre won't build without threads enabled either.


> TW> > Forks are the standard IPC method for perl5. Event-driven stuff (AE/EV) is a
> TW> > more advanced way, but for 40 parallel requests the forks are just ok.
> TW>
> TW> I'm not sure IPC means what you think it means - or I'm
> TW> misunderstanding you - It's Inter-process communication, right?
> TW> It'd say that forking, threading, and event-driven, are all methods of
> TW> doing simultaneous processing - but don't specify anything about IPC.
>
>
> Right. I just use to avoid telling many words like 'method of doing
> simultaneous processing' in favor of 'perlipc' in this case because:
>
>    $ man perlipc | grep fork | wc -l
>          37
>    $ man perlipc | grep thread | wc -l
>           4
>
> and having several perl processes to communicate between is made just easier
> by mean of fork().

How is fork() making it easier to communicate between processes? On
the contrary, I say that using threads::shared makes it far more
easier than fork() and rolling your own IPC.


> TW> Which is the reason I was using threads - it's easy to do IPC between
>
> ... processes? (=
>
> TW> them by sharing access to some data structures.
> TW> Whereas with forking you need to set up pipes, posix shared memory,
> TW> sockets, or some other means.
>
> Memory-mapped file doesn't seem to be bad:
>
>    https://metacpan.org/module/IPC::MMA

As far as I can tell, that doesn't offer any way to perform
synchronisation/condvars or suchlike - ie. where you can control the
flow of one thread from another.


> TW> In the end, I bit the bullet yesterday and did rewrite the code to use
> TW> fork(), and then used Net::STOMP::Client with RabbitMQ to perform the
> TW> IPC.
>
> Ouch. Isn't *MQ about to 'lose data under some circumstances' ?

No, not really. What makes you think that?
It depends entirely on how you configure and use it - you can have
messages you want it to make sure you really, really don't lose - or
you can have messages that are more transient.

-Toby

-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world