This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tolj@wapme-systems.de: Re: Problem with accept?!!


Corinna Vinschen wrote:
Thomas,

On Tue, Jun 03, 2003 at 12:48:41PM +0200, Corinna Vinschen wrote:

On Tue, Jun 03, 2003 at 11:44:13AM +0200, Thomas Pfaff wrote:

Attached are my changes so far, i will do some further testing.

Cool! I didn't know that the WinSock error is thread specific. With your changes it looks way better. Are you going to check that in?


btw., there's a problem left.  When signal_arrived is triggered, the
thread is terminated using TerminateThread().  As mentioned before, the
problem with this approach is that TerminateThread() leaves dangling
handles which are only removed by exiting the application.

I was already experimenting with the old WSASetBlockingHook stuff but
it doesn't work well.  So it just occured to me that we could do sth.
similar as in cygwin_select.  What about creating *another* socket in
the main function which only function is to be able to be select()ed.
Then, as soon as signal_arrived is triggered, this socket gets closed
by the main thread.  The result would be that select() returns and we
can leave the accept/connect_thread gracefully instead of terminating
it.

Good? Bad? Ugly?

I do not know if i understand you right but:


If you see a chance to use cygwin_select instead of winsock_select than there is no need to terminate the threads since they must not be used at all, the accept/connect thread stuff can be moved in the mainthread since cygwin_select is already interruptible.

Thomas



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]