Perl threads and libwww wierdness

[Peter Vereshagin]

Hello.

2011/12/19 18:31:53 +1100 Toby Wintermute <tjc at wintrmute.net> => To London.pm Perl M[ou]ngers :
TW> > 2011/12/16 12:38:16 +1100 Toby Wintermute <tjc at wintrmute.net> => 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>
TW> > TW> I know it certainly wasn't recommended back in the days of 5.6 or 5.8,
TW> > TW> but I thought things had improved since then..
TW> >
TW> > They did. Perl6 was released and it seems to have threads those can be recommended.
TW> > Perl5 have fork() that 'just works' and seems to be enough.
TW> 
TW> So, you're saying that threads under perl5 is forever going to be

Nothing in this world is forever. Chinese use to tell that  if the one will be
sitting near the river then that someone will see a floatiing dead corpse of a
his/her enemy floating nearby in the water. Some day.

TW> considered broken and not worth touching then? :(

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.

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

Do you note why it won't?

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

I don't (yet) own any of the IPC, sorry. (=
Do you own a one for a comparison then? (=

TW> > TW> Which is the reason I was using threads - it's easy to do IPC between
TW> >
TW> > ... processes? (=

Right, processes. :)

TW> > TW> them by sharing access to some data structures.
TW> > TW> Whereas with forking you need to set up pipes, posix shared memory,
TW> > TW> sockets, or some other means.
TW> >
TW> > Memory-mapped file doesn't seem to be bad:
TW> >
TW> >    https://metacpan.org/module/IPC::MMA
TW> 
TW> As far as I can tell, that doesn't offer any way to perform
TW> synchronisation/condvars or suchlike - ie. where you can control the
TW> flow of one thread from another.

Sure, it just doesn't 'use threads;' (=
But I'm pretty sure 'perdoc perlipc' will offer you such a way for processes,
not for threads or suchlike - ie. semaphores

TW> > TW> In the end, I bit the bullet yesterday and did rewrite the code to use
TW> > TW> fork(), and then used Net::STOMP::Client with RabbitMQ to perform the
TW> > TW> IPC.
TW> >
TW> > Ouch. Isn't *MQ about to 'lose data under some circumstances' ?
TW> 
TW> No, not really. What makes you think that?
TW> It depends entirely on how you configure and use it - you can have

Because configuration can be a circumstance in some cases.

TW> messages you want it to make sure you really, really don't lose - or
TW> you can have messages that are more transient.

Ok but... why does your task makes *MQ ( sounds more about a FIFO-kind to me ) more preferable than, say, MemcacheDB ( means about key-value pairs storage to me )?

--
Peter Vereshagin <peter at vereshagin.org> (http://vereshagin.org) pgp: A0E26627