[To Marc: oops. I keep replying to the wrong address. Sorry] > > I don't quite understand that, unless you're meaning that FD_WRITE is > > edge-triggered. > > Exactly (but that's not the only problem you also have to generate > events for connects and accepts - although this could probably be > handled by doing handle type detection in some way, and some quite > horrible code - at least, thatw as my impression :).
Why would FD_CONNECT and FD_ACCEPT not work? > > In that case, wouldn't it be possible to mark sockets that have > > writability signaled 'writable' and using a zero-timeout select() > call > > to determine if those sockets are still writable just before invoking > > the next wait? > > Yeah, but since we are callign select anyway, what again is the > advantage > of select+extra high overhead stuff vs. just select? The advantage would be that wait() can wait for other stuff. I don't really mean to check 'writability' and 'readability' of other handles, but just wait for some handle to become signaled. For example I need to wait for a child process to terminate. ev_child won't work because it relies on SIGCHLD which doesn't exists on windows. That doesn't mean its difficult to wait for a child process: windows will signal the child process handle as soon as the child process exits. But select can't wait on that handle. Same story for console input: you can wait for a console handle, but not with select. So my idea was to add a windows-only ev_winhandle watcher type to handle that kind of stuff, but then I need a libev backend that does wait for handles while not regressing over the existing select backend otherwise. Wrt the performance impact. Select is particularly slow when you try to select on a lot of handles. That wouldn't be needed in this case, because now we'd need to select only on sockets for which FD_WRITE is disarmed. > In theory, it would be possible to make a non-default backend that > has additional requirements (as kqueue basically is on many operating > systems), such as signalling write result codes or somesuch, It could be an alternative to the select trick, if that's what you mean. It is known that, as long as a socket op doesn't fail with WSAEWOULDBLOCK it is writable. And if it does FD_WRITE is rearmed. > but since performance on windows is rather bad even with > "perfect" use of iocps and other advanced features, it's hardly > worth the effort - windows support is good to have, but obviously, > nobody is interested in performance when using windows. Sure. Performance isn't my primary concern here, although I wouldn't accept a big performance regression over the select backend proper. - Bert _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
