discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Here's my work untill now(WAS: Re: [Q] select equivalent in Win32 for no


From: S.J.Chun
Subject: Here's my work untill now(WAS: Re: [Q] select equivalent in Win32 for normal file?)
Date: Fri, 11 Jul 2003 17:35:05 +0900 (KST)

After reading MSDN reference, I found that select just work for SOCKET. And in 
Windows HANDLE and SOCKET
are almost interchangeable, but file descriptor is different thing(refer 
_open_osfhandle, _get_osfhandle). Till now,
I cannot find enough information on general "select()" replacement for Windows, 
so this patch is current status
of my patchwork... :-)

  ----- Original Message -----
  From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
  To: "S.J.Chun" <chunsj@embian.com>
  Sent: Fri, 11 Jul 2003 08:19:04 +0100
  Subject: Re: [Q] select equivalent in Win32 for normal file?

  
  On Friday, July 11, 2003, at 07:42 AM, S.J.Chun wrote:
  
  > But when I run call which uses standard
  > in/out/err and they should be monitored in NSRunLoop, it does not 
  > work. Now here comes the question, is there
  > any equivalent method or call for select for normal file or 
  > stdin,out,err like descriptors?
  
  Well, select() *should* work for all descriptors, but I think it's a 
  known bug that select()
  does not work properly on windows :-(
  
  > And how can I know
  > given descriptor is for socket or for file?
  
  I don't know whether you can ... hence my suggestion of a flag in 
  GSFileHandle to differentiate
  between a usable descriptor and a windows file handle, and additional 
  code in NSRunLoop to
  handle the two cases differently.
  
  It may be that it *is* possible to find information about a descriptor 
  on windows which will tell you how you can use it ...  but I haven't 
  been able to find it.  Windows I/O is a *BIG* mess, the API is really 
  lousy and has lots of different mechanisms for doing the similar things 
  (all with drawbacks).
  The select() call doesn't work on all file descriptors as it should, 
  but it does allow you to watch a large number of descriptors.  The 
  various windows functions for waiting for I/O events don't map well to 
  the NSRunLoop structure and only let you watch 64 handles etc.
  
  

Attachment: file.mingw.patch.gz
Description: application/gzip-compressed


reply via email to

[Prev in Thread] Current Thread [Next in Thread]