Arend van Beelen wrote: > thanks for your thorough reply! I'm glad to see the first option appears to > be preferred, as it was my first choise as well. The main reason I had some > doubts was because a colleague of mine quite strongly argued (though I was > still not entirely convinced) that I would find myself in an aweful lot of > trouble when trying to implement a multi-threaded library inside a > single-threaded PHP environment. Which is the problem I am hoping to solve by > only exporting a single-threaded API.
I would lean towards an event-driven approach along the lines of select() and curl_multi. You could probably copy a lot of the code from the curl_multi implementation since essentially you are doing the same thing. And yes, your colleague is correct, you will have issues doing a threaded library. Portability, threading clashes, signal handling, etc. And I don't see how scheduling is a factor here at all. On a busy web server your OS is already spreading things out over all your cores. You don't need intra-request scheduling of threads on top of that. A simple single-threaded event-driven model keeps things clean. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
