[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: New Event API for Luasocket
- From: Daniel Quintela <danielq@...>
- Date: Fri, 25 Jun 2004 11:01:02 -0300
Hi:
> So for POSIX environments all is fine and dandy. But I still need feedback
> on the situation for Windows with all these different kinds of handles
> (sockets vs. kernel vs. C runtime). I'm royally confused by the stuff
> I've read over at MSDN. I bet someone else will step in and educate me.
Even two Sockets handles from different Providers can't be used in a select
!!.
I think WaitForMultipleObjectsEx is the best api to keep the things simple.
It can wait on:
- Change notification
- Console input
- Event
- Job
- Mutex
- Process
- Semaphore
- Thread
- Waitable timer
- APC
> Overlapped IO would seem to be the way to go for socket IO.
> There are many options for implementing Overlapped IO in
> your event based model. IOCompletionPorts are my preferred
> option. Variant behaviour exists across Win9x/NT/2000/XP/2003.
Alternative: WSAEventSelect associates an Event with a Socket (indirect
method to use sockets with WaitFor...).
> If we can ignore 95/me then life is not too bad.
Windows 98 (and up) supports MsgWaitForMultipleObjectsEx, adding the thread
message queue as another source of events (good for GUIs).
> Use either Windows API or the C runtime not both.
I agree with these, but using native handles gives us a more general
solution.
Remember: there is a limit of 64 handles in any WaitFor... call.
Windows has many ways to do the same thing, is not easy to choose the best
one.
Regards,
Daniel