Re: Windows POSIX
Hi Conrad, On Tuesday 22 February 2005 04:34, Conrad T. Pino wrote: How does abstracting all CVS I/O calls for files, pipes and sockets sound to you? Emulating non-blocking I/O (including select()) with Windows API functions (asynchronous ReadFile()/WriteFile() and WaitForMultipleObjects()) is a nightmare. For instance a) you cannot cancel an asynchronous ReadFile() operation and then reliably determine the amount of data already read. b) cancelling a ReadFile() operation (via CancelIo()) automatically cancels any other I/O operation on the same handle c) you cannot determine the amount of data which can be read immediately (without blocking) for all kinds of input sources. Non-blocking writing has its own problems. Maybe there is an easy solution for this, but I have not yet found it. Kind regards Ingolf -- Ingolf Steinbach Jena-Optronik GmbH [EMAIL PROTECTED] ++49 3641 200-147 PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04 ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Windows POSIX
Maybe there is an easy solution for this, but I have not yet found it. What about taking some code/adapt code from cvsnt? I have not taken a detailed look at it, but there must already be some abstraction done ... Frank ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Windows POSIX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Derek, New thread started from Frank Hemmer's :ext: with ssh failure on w2k - patch thread. I agree with Frank that Windows select implementation accepts neither pipe nor file descriptors. Microsoft claims POSIX compliance for Windows but IMO it's no where near the level the UNIX world supports. In addition to the select problem, Windows does NOT implement fcntl at all. Where open, read, write, close, etc. are kernel functions in UNIX, the same are C run-time functions in Windows Visual C++ and non-blocking I/O isn't supported at all. I could go with details but the points I want to raise are: 1. CVS does NOT abstract POSIX low level I/O: open, read, write, close, select, etc. 2. Microsoft is unlikely to advance POSIX compliance for Windows to be sufficiently useful. Over the long term we're confronted with providing real POSIX support for Windows OR dropping Windows support. I prefer to avoid the latter. As I see it if we are to continue down the path toward better performance of the current src/buffer.c then we should replace Microsoft's poor implementation with our own. Can you quickly enumerate a list of functions that we need to replace to keep moving forward on the current performance improvement path? Is it sufficient to replace the problematic functions relying on the linker to use our implementation without using a macro such as CVS_OPEN for open? Best regards, Conrad -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQhp4WbNM28ubzTo9EQIkYQCgnofaeW9JueAdGFd7RaNhHa6JI8UAn3cf vmGU3Q2PG1dmY5lUe7ELjhAi =zUOy -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Windows POSIX
Hi Derek, My Visual C++ 6.0 installation has source for the C Run Time library. File handles returned by open and create are NOT Windows API level file handles. They are an index into arrays of an internal library structure which contains a field for saving the Windows API level file handle. The Windows Socket API says socket handles MAY be used as Windows API level file handles: http://msdn.microsoft.com/library/en-us/winsock/winsock/socket_handles_2.asp Not as definite as I would prefer. To assure POSIX semantics it seems we need to insure file and socket handles exist in a single number space so they can be used together in a select implementation. How does abstracting all CVS I/O calls for files, pipes and sockets sound to you? Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
