Don't you mean "task::spawn_root_and_wait(tb);" instead of "tb.execute();"?

Perhaps something resembling the following (don't forget to get rid of cpt at some point):

thread_accepts_connect()
{
...
tbb::empty_task& cpt = *new( tbb::task::allocate_root() ) tbb::empty_task;
while(1)
{
client_sockfd = accept ();
ProcessSocketTask& fb = *new( cpt.allocate_additional_child_of( cpt ) ) ProcessSocketTask(client_sockfd);
cpt.spawn(fb);
}
}

(Added) Sorry, that was rushed, and without heeding my own advice to interface I/O to TBB using a concurrent data structure or so, with proper scheduling being program-specific. The suggested code is bad for numerous reasons: there is no bound on the number of tasks spawned before the process runs out of sockets, the tasks will still do I/O and may occasionally block, TBB is unfair even between the spawned tasks, and the tasks may be starved if TBB is otherwise occupied. No likely solution will spawn a task per socket (perhaps per data packet).

(Corrected) allocate_additional_child_of() is not static, but I have not actually verified this (it was rushed, and is probably not worth verifying).

See new correction above, but note the "perhaps" and the correction comment. I defer to others for further suggestions about a likely solution (not by spawning tasks for sockets), I'm curious myself and I'm afraid I have not yet studied Robert Reed's blog; maybe even parallel_for on the file descriptors after select/poll discovers available data, followed by a pipeline on complete packets.