flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
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? |
|||
![]() |
|
asmhack 02 Jul 2008, 16:29
thread ?
|
|||
![]() |
|
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. |
|||
![]() |
|
LocoDelAssembly 02 Jul 2008, 17:11
|
|||
![]() |
|
asmcoder 03 Jul 2008, 13:09
[content deleted]
Last edited by asmcoder on 14 Aug 2009, 14:57; edited 1 time in total |
|||
![]() |
|
f0dder 03 Jul 2008, 13:19
asmcoder wrote: lock a thread on recv, and optional another ony on send _________________ carpe noctem |
|||
![]() |
|
asmcoder 03 Jul 2008, 14:17
[content deleted]
Last edited by asmcoder on 14 Aug 2009, 14:57; edited 1 time in total |
|||
![]() |
|
f0dder 03 Jul 2008, 14:41
asmcoder wrote: events, why? 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 |
|||
![]() |
|
asmcoder 03 Jul 2008, 15:01
[content deleted]
|
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.