G>>Во-первых, ты не прав — это на самом деле сделать возможно. Достаточно шедулер (или его часть) запустить в другом потоке, который будет делать отсечку по времени, и все. Видишь ли в чем дело — SwitchToFiber можно вызывать из другого потока — это совсем не обязательно делать из активного файбера.

G>>"Пробовал ли ты? А ты попробуй!" Тебе надоели тред-пулы?

G>>Задолбали "паттерны" параллельного проектирования? Хочется чтоб алгоритмы выглядели по человечески — свой "поток" на каждую истинно параллельную активность в системе? Чтобы их крутились десятки тысяч, и все было нормально? Нет времени и желания рефакторить старый код, чтобы он стал thread-safe? Тогда пиши свой файберный планировщик, в котором любая операция O(1) — задачка, скажу тебе, не слишком простая , но и не очень сложная — я уложился в 468 строк на С++.

class FiberEvent
{
    bool m_bState;
    
    typedef std::list< Task * > WaitingTaskList;
    WaitingTaskList m_waitingTaskList;
public:
    FiberEvent( bool i_bState = false );
    explicit FiberEvent( const FiberEvent & i_event );
    FiberEvent & operator = ( bool i_state );
    operator bool() const;
    
    void Set();
    void Reset();
    void Wait();
};

FiberEvent & FiberEvent::operator = ( bool i_state )
{
    if( m_bState != i_state )
    {
        if( i_state )
            for( WaitingTaskList::iterator it = m_waitingTaskList.begin(); it != m_waitingTaskList.end(); ++it )
                (*it) -> ResumeTask();

        m_bState = i_state;
    }
    
    return *this;
}

void FiberEvent::Wait()
{
   if( !m_bState )
   {
      m_waitingTaskList.push_back( Task::ReplyCurrent() );
      Task::ReplyCurrent() -> StopTask();
   }
}

inline void Yield()
{
   if( Task::QuantIsExceeded() )
      Task::Return();
}

#define _WIN32_WINNT 0x0400
#include <windows.h>
#include <stdio.h>
#define Q_STACK_SIZE 4096
VOID CALLBACK FiberProc (PVOID lpParameter)
{
  puts ("FiberProc Start");
  ::ExitThread (666);
  puts ("FiberProc End");
}
LPVOID g_fib1 = 0;
LPVOID g_fib2 = 0;
int g_fdata1 = 1;
int g_fdata2 = 1;
int g_tdata  = 2000;
DWORD WINAPI ThreadProc (PVOID lpParameter)
{
  puts ("ThreadProc Start");
  g_fib1 = ::ConvertThreadToFiber (&g_fdata1);
  g_fib2 = ::CreateFiber (Q_STACK_SIZE, FiberProc, &g_fdata2);
  puts ("ThreadProc Deadlock");
  for (;;);
}
int main(int argc, char* argv[])
{
  DWORD tid = -1;
  HANDLE  htr = ::CreateThread (0l, Q_STACK_SIZE * 4, ThreadProc, &g_tdata, 0, &tid);
  ::Sleep (1000);
  puts ("Killing deadlocked thread...");
  ::SwitchToFiber (g_fib2); // Здесь мы падаем ;(
  puts ("Success");
  ::Sleep (1000);
  return 0;
}

You can call SwitchToFiber with the address of a fiber created by a different thread. To do this, you must have the address returned to the other thread when it called CreateFiber and you must use proper synchronization.

std::vector<char> accumulator;

void OnIcomingData()
{
    if (state==READING_HEADER)
       readHeader();
    else if (state==READING_BODY)
       readBody();
    else
       assert(false);
}
void readHeader()
{
    channel.read(accumulator);
    if (обнаружен_конец_заголовка)
    {
       //парсим заголовки, очищаем аккумулятор
       state=READING_BODY;
    }
    else
       return; //состояние не изменилось, накапливаем данные в аккумуляторе
}
....

void read_request()
{
    Header hd;
    while(!hd.finished())
    {
       std::string str;
       str=channel.read_line(); //Sic!
       hd.parse_line(str);
    }
    //читаем тело и т.п.
}

parseHeader();
parseBody();
parseEpilogue();

class FiberTask
{
// Top secret NDA covered code skipped...
    virtual void                        beforeTimeQuant(){}
    virtual void                        afterTimeQuant() {}
};

GN>Свой планироващик может быть удобнее, проще решать задачу, или ещё что-то там, но в ряде случаев он будет похож на человека пытающегося заплыть на водопад .

G>>При чем здесь CPU? Синклер, не пугай меня. Ты конечно же в курсе, что планировщик задач в оперсистеме распределяет процессорное время между готовыми к выполнению задачами, и ничего другое, и, надеюсь, не станешь убеждать меня в обратном.

S>Ну, пул динамически будет увеличен

WaitForAll( i_events )
{
   for all event in i_events
       event.Subscribe( Task::ReplyCurrent() );

   // для каждой задачи в состоянии поддерживается количество объектов, которых она ждет. По сути,
   // это счетчик ссылок со стороны примитивов синхронизации.
   while( Task::ReplyCurrent() -> GetWaitingForCount() )
      Task::ReplyCurrent() -> StopTask();
}

GN>>Я видел его адресное пространство в отладчике SoftICE .

ADDR
Display or switch to an address context.

Syntax
ADDR [process-name | process-id | KPEB]

process-name
Name of any currently loaded process.

process-id
Process ID. Each process has a unique ID.

KPEB
Linear address of a Kernel Process Environment Block.

Use
Use the ADDR command to both display and change address contexts within SoftICE so that process-specific data and code can be viewed. Using ADDR with no parameters displays a list of all address contexts.

If you specify a parameter, SoftICE switches to the address context belonging to the process with that name, identifier, or process control block address.

addr explorer

addr idle

The System process holds operating system kernel threads and device driver threads, and Interrupts and DPCs are artificial processes that Process Explorer uses to display interrupt and Deferred Procedure Call (DPC) activity.

"закат солнца в ручную"

User-Level Threads

User-level avoids the kernel and manages the tables itself. Often this is called "cooperative multitasking" where the task defines a set of routines that get "switched to" by manipulating the stack pointer. Typically each thread "gives-up" the CPU by calling an explicit switch, sending a signal or doing an operation that involves the switcher. Also, a timer signal can force switches. User threads typically can switch faster than kernel threads [however, Linux kernel threads' switching is actually pretty close in performance].

Disadvantages. User-level threads have a problem that a single thread can monopolize the timeslice thus starving the other threads within the task. Also, it has no way of taking advantage of SMPs (Symmetric MultiProcessor systems, e.g. dual-/quad-Pentiums). Lastly, when a thread becomes I/O blocked, all other threads within the task lose the timeslice as well.

Solutions/work arounds. Some user-thread libraries have addressed these problems with several work-arounds. First timeslice monopolization can be controlled with an external monitor that uses its own clock tick. Second, some SMPs can support user-level multithreading by firing up tasks on specified CPUs then starting the threads from there [this form of SMP threading seems tenuous, at best]. Third, some libraries solve the I/O blocking problem with special wrappers over system calls, or the task can be written for nonblocking I/O.

Cthreads is a user-level threads package that runs on several uniprocessors and multiprocessors. It offers support for shared-memory parallel programming. The uniprocessor support is intended for development, debugging and classroom use. Cthreads should work on the following architectures/operating systems:
Sun Sparc SunOS 4.1.3
Sun Sparc Solaris 2.x
SGI MIPS IRIX 5.x
SGI MIPS (32 and 64-bit) IRIX 6.x
IBM RS6000 AIX 3.2
x86 Linux (now Redhat 5.1)
x86 Solaris 2.x
Windows NT

C>parseHeader();
C>parseBody();
C>parseEpilogue();
C>

switch (parseHeader())
{
    case BodyType1:
        parseBodyType1();
        break;
    case BodyType2:
        parseBodyType2();
        break;
    ...
}
parseEpilogue();