Re: Using GNUstep with MINGW

[Michael Scheibler]

Richard Frith-Macdonald wrote:
> 
> On Tuesday, December 5, 2000, at 09:21 AM, Helge Hess wrote:
> 
> > Hi,
> >
> > I've encountered that problem with libFoundation as well. I'm pretty
> > sure that a Win32 runloop core needs to be rewritten completly, based on
> > multithreading where a thread waits on one specific event source.
> > This can be useful for Unix as well, eg if you want to support SHM for
> > DO communications (not everything is select'able in Unix as well).
> >
> > BTW: What exactly do you want to wait for ?
> 
> I'm interested too.
> 
> If you are contemplating a threaded implementation of NSRunLoop ... which 
> shouldn't
> actually be *too* hard ... I'd suggest using native threads directly rather 
> than NSThread.
> In principle this could be done such that the threads actually waiting for 
> events never
> touch the GNUstep data structures, and the GNUstep thread waits on a lock.  
> This would
> mean that the GNUstep app would never need to become multi-threaded as far as 
> NSThread is
> concerned - and could avoid the need to use locks anywhere else.  This would 
> avoid the
> considerable locking overheads involved when an OpenStep app becomes 
> multithreaded.
> 
> Any code donations gratefully accepted of course :-)



I've done it.
I rewrote NSRunLoop's acceptInputForModes: beforeDate: method to listen
to WIN32 events. These events enter signaled state, when a file
operation in overlapped mode has finished.
When you use a file operation in overlapped mode, windows runs a
separated thread. You don't have to care about synchronization, you just
have to check the associated event object.