That is exactly what node seems to do with the zlib API.  Though there are 
times where this is great, this API definitely bothers me, and causes some 
problems.  In theory, if I have a 4 core machine, and have 4 busy node 
processes, and each of them try to use the zlib API, suddenly I've got 8 
cores worth of threads all fighting for the CPU (or, possibly many more if 
multiple zlib requests are made and each process has a thread pool equal to 
the number of cores?).  Since zlib stuff is CPU-intensive, not I/O 
intensive, it would be great if there was a synchronous API so that we can 
ensure the handling of a single task (whether it be expensive JS code, or 
zlib operations) is consuming only a core.  The async API on Zlib stuff 
seems odd when compared to the Crypto APIs, which are all synchronous, 
despite being, I think, quite more CPU-intensive (per-byte) than Zlib.

Admittedly, there are OS-level CPU affinity masks which could be used here, 
but in general that's not particularly good for overall performance.

On Thursday, October 25, 2012 2:39:10 PM UTC-7, Mark Hahn wrote:
>
> > Are you saying that node, internally, delegates CPU intensive work to 
> background threads?
>
> What the heck are you talking about?  There is no such feature and there 
> shouldn't be.
>
>

-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Reply via email to