2009/10/27 Phil Dawes <p...@phildawes.net>: > Paul Moore wrote: >> Hmm, no I thought I understood this, but I don't really. You're saying >> that the current API is something along the lines of >> >> create-vm ( startup-args -- ) >> >> How's that any better than spawning a completely new Factor process? >> > > Good question! Not much probably.
:-) > To be honest if every platform I was interested in was a unix I would > have just used fork. In fact fork is cleaner because I could use a local > variable for the parent pipe and the child process would be able to use > this directly without faffing about with locks and stuff. Hmm, yes, it's the biggest conceptual mismatch between Unix and Windows - multiprocessing with fork on Unix is easy enough that threads aren't really that big a deal (in fact, IIRC, on Linux at least at one point, threads were implemented as some sort of stripped down forked process, with memory sharing). But on Windows, threads are far more lightweight than processes, and make much more sense. > Anyway, using tcp for communication between processes on windows was > just clunky enough that I wondered if I how difficult it would be to run > a bunch of factor vms in the same process, and that's what started me > down this road. Ugh yes. And then you end up with talking between the threads not being that much easier :-) Just a thought - I wonder how hard it would be to implement some sort of fork-like API at the factor level, using multiple VMs and threads on Windows? Perl did something like that with their threading support, I believe. Probably the biggest issue would be duplicating the heap and stuff like that... > I'm still not sure if running many vms in a process is as useful as it > sounds, but the reentrant code changes are a step towards true native > threading so I guess if it doesn't work out it's still a useful step. My main interest is playing with a highly CPU-bound (toy) problem I have, where I'd love to be able to use my dual-core PC to its full potential. Thread pools, parallel map and things like that would be really cool, but they need to be layered on top of real OS threads, rather than factor's current threads. Paul. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
