Show me how the concurrency limiter actually queues tasks.

The concurrency limiter queues tasks through a two-stage promise mechanism in the enqueue function [index.js:L46-L57].

How it works:

1. Queue Creation: A Queue object stores pending tasks [index.js:L14].

2. Enqueue Process: When you call limit(fn), it creates a new Promise that wraps the queuing logic [index.js:L60-L62]:

   const enqueue = (function_, resolve, reject, arguments_) => {
       const queueItem = {reject};
       
       new Promise(internalResolve => {
           queueItem.run = internalResolve;
           queue.enqueue(queueItem);
       }).then(run.bind(undefined, function_, resolve, arguments_));
   

   The key insight: instead of queueing the run function directly, it queues a resolver callback (internalResolve). This preserves the async execution context.

3. Concurrency Check: If we haven't hit the concurrency limit, resumeNext() is called immediately [index.js:L55-L57]:

   if (activeCount < concurrency) {
       resumeNext();
   }
   

4. Dequeue & Execute: resumeNext() checks if there's capacity and space, then dequeues the item and calls run() [index.js:L17-L22]:

   const resumeNext = () => {
       if (activeCount < concurrency && queue.size > 0) {
           activeCount++;
           queue.dequeue().run();  // Calls internalResolve, triggering .then(run...)
       }
   };
   

5. Task Completion: After the task finishes, next() decrements activeCount and processes the next queued task [index.js:L24-L27].

The queue is passive—tasks don't execute until resumeNext() resolves them.

FOLLOW_UPS:

• What does the Queue data structure look like?
• How does activeCount and pendingCount get exposed?
• What happens when clearQueue is called?