Re: Threading vs perl

Replies are listed 'Best First'.
Re^2: Threading vs perl by poqui (Deacon) on Jun 20, 2005 at 18:39 UTC
Once upon a time I was working at a different company, and we had a real-time process that generated statistics. We had 2 classes of hardware, one windows based, and one Dec Unix based. The Windows based systems (NT) had support for threads, so we used a back end program to watch the socket for messages, collect the messages, and periodically push the messages to the Informix db, in 2 threads. The Dec Unix system didn't support threads, so we used multi-processes with IPC. I think it was 3. They both did the same thing, but we worked within the limitations of what we had at the time. I guess the point is that both approaches worked, and were relatively efficient. But for my part, the multi process approach was much easier to work with and figure out what was happening when something went wrong. The multi thread approach took me longer to get working well. But that might have been because it was on Windows. I haven't done any multithreading on any other platform.	[reply]
Re^2: Threading vs perl by Eyck (Priest) on Jun 20, 2005 at 12:10 UTC
For example java needs threads because it can't (couldn't) do asynchronous IO, Thus, by your logic, perl needs no threads? yet some monks can't live without'em, why? Background processing should work on different set of data then the GUI itself, thus, I would think, that forking off the process to do the job would be the best. Languages are not created equal, you seem to be suggesting to keep feature count high, I don't know why, to look ok on comparision charts? Does perl need continuations? I would sure like them, even instead of threads.	[reply]
Re^3: Threading vs perl by spurperl (Priest) on Jun 20, 2005 at 13:12 UTC
Perl can do asynchronous IO, but it still needs threads. Nothing to claim the opposite "by my logic". Asynchronous IO is great, but in some applications it's not enough, and threads are better. This becomes especially useful in applications with GUIs. You can use Tk's "after" utility to simulate multitasking, but it ain't pretty. Using threads is much, much better, and far more comfortable. Threads make it very easy and quick to share data between units of execution, unlike processes. When you have a manager-workers model that requires a lot of data to be passed around quickly, threads come in very useful. Continuations won't come instead of threads. While they make "cooperative execution" possible, it's not what they really are for, as far as I understand. You still have to decide when to give up control, and with many paths of execution it's important that this is done quickly and efficiently.	[reply]
Re^4: Threading vs perl by Eyck (Priest) on Jun 20, 2005 at 13:42 UTC
It seems like people are taught GUI programming with threads and thats the reason for this this strange popularity among younger monks. What is really fun is this, statements like "but it still needs threads." are really pleasing to some monks, while "why actually?" make them angry. I can't really understand this,	[reply]
Re^3: Threading vs perl by ruoso (Curate) on Jun 20, 2005 at 16:20 UTC
forking off the process to do the job would be the best. Do you realize that forking is very much different from threading? Fork actually copy the memory from one process to another, causing more memory use. A forked proccess can only comunicate with the parent process with IPC and shared memort. With threads the memory is shared, and you don't need to handle that. The question is that there are uses for fork and for threads, and using threads when forking is better is as bad as using fork when threading is better. Do you want an example? First: Implementing a networking application that needs to continuosly read and continuosly write from sockets. It can be done with fork, but it would be much better (from an OS view) to do with threads. Second: JBOSS uses too much threads and too few forks. The result is that I can easily see it eating 900 Mb of RAM beause of some jobs that uses more memory, if it did fork, these procesess that eat memory would run in a forked procecss and the memory would be given back to the Operating System. I think there is no way to say "Why do I need threads, since I have fork?"... It's the same to say "Why do I need a car, since I have a stomach?"... daniel	[reply]
Re^4: Threading vs perl by chromatic (Archbishop) on Jun 20, 2005 at 18:00 UTC
Fork actually copy the memory from one process to another That depends on the operating system. I don't know of any Unix-like OSes worth using that don't have copy-on-write for forking. With threads the memory is* shared* That depends on the threading model. With a shared-everything model, threads can safely share most of everything (except for parts of the execution context). Of course, then you have the potential for deadlocks and weird execution order if you want atomic operations where it matters. With a shared-almost-nothing model, you won't even have the potential memory savings of copy-on-write unless the implementors did a lot of work. if it did fork, these procesess that eat memory would run in a forked procecss and the memory would be given back to the Operating System. The OS should reclaim the copied memory pages, yes, but not the shared memory pages.	[reply]