flat assembler
Message board for the users of flat assembler.

Index > Windows > Winsock without blocking the GUI?

Author
Thread Post new topic Reply to topic
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY 02 Jul 2008, 16:09
Anyone have an example of a GUI server using winsock without getting the GUI blocked when listening?

What's the easiest way to fix it?
Post 02 Jul 2008, 16:09
View user's profile Send private message Reply with quote
asmhack



Joined: 01 Feb 2008
Posts: 429
asmhack 02 Jul 2008, 16:29
thread ?
Post 02 Jul 2008, 16:29
View user's profile Send private message Reply with quote
ManOfSteel



Joined: 02 Feb 2005
Posts: 1154
ManOfSteel 02 Jul 2008, 17:08
Or WSAAsyncSelect.

Basically it enables you to setup a custom message that will be passed to your window on every network event.
Post 02 Jul 2008, 17:08
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 02 Jul 2008, 17:11
Post 02 Jul 2008, 17:11
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3174
Location: Denmark
f0dder 03 Jul 2008, 12:53
In case you want decent performance (either high throughput or lots of clients), you need I/O Completion ports or WSAEventSelect - and you want nonblocking sockets.

If you're only going to support a very few simultaneous connections, you can go through with threads + blocking sockets, but since you're likely to need synchronization, doing a proper EventSelect from the start is the smartest way to go.
Post 03 Jul 2008, 12:53
View user's profile Send private message Reply with quote
asmcoder



Joined: 02 Jun 2008
Posts: 784
asmcoder 03 Jul 2008, 13:09
[content deleted]


Last edited by asmcoder on 14 Aug 2009, 14:57; edited 1 time in total
Post 03 Jul 2008, 13:09
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3174
Location: Denmark
f0dder 03 Jul 2008, 13:19
asmcoder wrote:
lock a thread on recv, and optional another ony on send
"block", not "lock". And again, smarter to do things properly and set up events.

_________________
carpe noctem
Post 03 Jul 2008, 13:19
View user's profile Send private message Reply with quote
asmcoder



Joined: 02 Jun 2008
Posts: 784
asmcoder 03 Jul 2008, 14:17
[content deleted]


Last edited by asmcoder on 14 Aug 2009, 14:57; edited 1 time in total
Post 03 Jul 2008, 14:17
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3174
Location: Denmark
f0dder 03 Jul 2008, 14:41
asmcoder wrote:
events, why?
if many clients connect, all of them will lag. Maybe thread eats a lot of memory, but thats m$ bug, idea of socket thread is good.

I'll try being patient with you. First of all, thread-per-socket is not a good idea, and Win32 threads are pretty lightweight - certainly more lightweight than the typical unix idea of "a process per connection". You can only have a limited number of threads though, with 4k stacks I managed to create somewhere between 1000 and 2000 threads on win32. But doing something like that is flawed, even if threads will mostly be BLOCK_WAITING.

With the event socket model, you create an array of MAXIMUM_WAIT_OBJECTS linked lists. Each list entry will have the required client state information. You add new clients to the list that currently has the fewest entries. You then associate an array of MAXIMUM_WAIT_OBJECTS event handles with your client-list. Then, after the necessary socket setup, you use a single thread to WaitForMultipleObjects on your handle array.

Once WFMO returns, you loop through the client link-list the triggered event corresponds to, handle any active sockets in the list, and finally re-issue a WFMO. You can either use this worked thread and a separate GUI thread, or you can add a timeout to WFMO and handle everything in one thread.

utorrent uses this technique to handle many clients, doesn't have trouble saturating a 100mbit link, and isn't very CPU intensive. Try doing that with a-thread-per-socket... even if you manage to use all lock-free algorithms and no synchronization primitives, I'll bet your CPU usage isn't very friendly. And complexity will be higher.

_________________
carpe noctem
Post 03 Jul 2008, 14:41
View user's profile Send private message Reply with quote
asmcoder



Joined: 02 Jun 2008
Posts: 784
asmcoder 03 Jul 2008, 15:01
[content deleted]
Post 03 Jul 2008, 15:01
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.