On 12 Jan 2009, at 12:20 pm, Mor Phir wrote:
I was wondering if anyone on the ml where using chicken in a enterprise enviroment.
*booming silence* I'm sure there was somebody!
scenario: You wanna utilize more cores and more cpus at your setup, how would you go about this?
Well, just run more chicken processes. Design your app so that lots of processes can cooperate. For an HTTP server accessing read-only or database-held state, this is easy: just run lots of http daemons and have a load balancing/failover setup (eg, whackamole) in front. Sharing state scalably is the hard part - and a problem I'm working on solving for my day job, he he he. But don't be put off by the lack of 'native threads' in Chicken. That would let you use more cores in one chicken process, if you wrote threads, but it can't scale beyond more than one physical server, while being multi-process can; and threads sharing in-memory state are a recipe for disaster (on the one hand, race conditions; on the other hand, deadlocks or no actual concurrency since everything is serialised around access to lock-protected structures). Threads have their uses, but shoving lots of independent worker threads into one process, rather than using them to gracefully ship out parts of an operation so they can complete in parallel where system resources allow, is dangerous! As a case of useful threading, part of the system I'm working on for work is a daemon that pulls messages from a multicast network and then applies the writes described in those messages to a disk. Writes that come in may overlap each other, often with a later write totally overwriting an earlier one, and writes may come in big bursts, so we have two 'threads': one that receives multicasts, unpacks them, and inserts them into a queue of writes, checking for overlaps and dealing with them there and then by discarding the obsoleted data, and another that processes writes from the queue and actually does them on-disk. One task is CPU-based, the other task is disk-based and involves a lot of waiting for the disk to do its work, so they are allowed to run independently (sadly, using asynchronous I/O isn't an option since the disk writes go through a third-party library that works in an inherently blocking way). However, because there is a precise master/ slave relationship between the two threads, it makes it a lot simpler to make sure that shared state - the queue - is thread-safe. If we had an arbitrary number of worker threads handling requests at once and competing over access to the queue, it'd be a lot harder. ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
