An SMP machine won't be used efficiently anyway because of the interpreter lock.
To me it seems a bit odd to have an implicit mapping between threads and backends; I'd probably use explicit backend objects or maybe round robin if I'm worried about having too many fd's in the same backend(*). In any case, it's simple to make your own dispatcher. Something like this:
class ThreadToBackendDispatcher { mapping(Thread.Thread:PikeBackend) map = ([]);
Stdio.File make_stdio_file_obj() { Stdio.File f = Stdio.File(); f->set_backend (map[this_thread()]); return f; }
void call_out (function f, int delay, mixed... args) { map[this_thread()]->call_out (f, delay, @args); }
// Etc... }
*) Grubba has lately been working a bit on using /dev/poll or similar (/dev/epoll on Linux). Where that method works, many fd's in the same backend shouldn't be a factor and so there's no reason at all to split the fd's into several backends. Right now it should work with 7.5 on Solaris if I'm not mistaken. I don't know how far he has gotten with the Linux support.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-01-23 05:54: Subject: Default backend and thread backends?
Hi,
Is there any way to _change_ default backend? Something like Pike.DefaultBackend->replace(MyBackend) - so all subsequent calls to call_out() and all file descriptors allocated after this will use new backend?
And more... It would be nice to have dedicated backends in some threads, so (say) all calls to call_out() and fd's allocation will use thread-specific backend (if it is set - and default otherwise). Something like Thread.Thread()->set_backend()...
All this functionality can be simulated(?) - like intercepting Stdio.File|Stdio.FILE object creation (to use Backend()->add_file()), call_out()s etc., but it wouldn't be as clean as "native" support (there is always chance to overlook something).
As to "Why?" - well, I simply don't want to (over)load single backend with callbacks from everywhere... Especially when I've SMP machine - it won't be used efficiently with single backend.
Any comments?
Regards, /Al
/ Brevbäraren