On Fri, Feb 03, 2006 at 11:18:58AM -0600, John Goerzen wrote:
On Fri, Feb 03, 2006 at 05:56:41PM +0100, Tomasz Zielonka wrote:
On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
I know, of course, that Java green threads and Haskell forkIO threads are called "threads", but I personally believe its misleading to call it concurrency -- they're not doing more than one thing at a time.
Aren't you thinking about Parallellism?
No.
http://en.wikipedia.org/wiki/Concurrency_%28computer_science%29 In computer science, concurrency is a property of systems which consist of computations that execute overlapped in time
You're not doing anything simultaneously ("overlapped in time") when you're using poll and select (only). To do something simultaneously in Unix, you'd have to either use fork() or start a thread.
Concurrent computations can be sliced into smaller pieces and interleaved - so there is no need to perform many things simultaneously. That's how Unix works on uniprocessors - at every time point the CPU is executing at most one task. Are you arguing that uniprocessor Unix doesn't provide concurrency? There are some differences between Unix and GHC process scheduling (I think that in some special cases GHC's threads can't be preempted, eg. in tight loops without allocations), but they are not that big. The point is that on a uniprocessor everything is performed sequentially at some level. When we talk about Unix, it's the level of OS implementation, with GHC it's the level of RTS. Yet in both cases we get quite a good impression of concurrent execution, and it's rather more productive to think in terms of concurrency. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland