Originally posted by lfroen
amuled can not be compiled on Win32 due to wx socket implementation. Your explanation of reasons, however is false all over.
Hmm ... that's strange. With a few tweaks to the wx sources I was indeed able to compile amuled on Win32 and do some tests with it. And it's not nice to say that my explanation of reasons is "false all over" without proving it. *grumble*
Socket handles are assumed to start at very low numbers which isn't always the case on Win32
That is not handle. That's descriptor. It have same value on Win32 too (surprize !).
On Win32 a file descriptor IS a handle (it's of type HANDLE). The "descriptor" for socket operations is a UINT_PTR to be able to contain a HANDLE (AFAIK) and will therefore not start with a value of 3 and will most likely have a number > FD_SETSIZE. That's the reason why I got lots of ASSERTions in the first place. Do your own tests if you don't believe me.
However, it's at least dangerous to use FD_SETSIZE as a limit and set the file descriptor value into direct relation to FD_SETSIZE ...
It uses "select" to wait for socket events and relies on internal wx socket API members that only exist for the unix platform
There's "select()" call on Win32 too (surprize again).
Yes, there is a select() function but you overlooked the second part of the sentence:
and relies on internal wx socket API members that only exist for the unix platform
To be more precise: It relies on Detected_Read and Detected_Write which have to be members of GSocket.
A solution would be using a thread for every connection
That is bad design decision. Number of threads per process is limited, and the number is not very high.
You're right, there is a limit:
From PSDK
The number of threads a process can create is limited by the available virtual memory. By default, every thread has one megabyte of stack space. Therefore, you can create at most 2028 threads. If you reduce the default stack size, you can create more threads.
FD_SETSIZE on the other side has a default value of 64 (if not defined to a different value before).
Using a thread for every connection doesn't lower the performance if developed carefully.
Yes it does. There's reason for that, it's called "context switch" with overhead of syscalls for locking datastructure.
That's why I wrote "developed carefully".
Sorry that I offered my help. However, it's good that I realized it before that there is such an unfriendly developer involved in this project. I didn't want to blame anyone here - I just tried to do some constructive comments and got flamed back with non-constructive answers.
However, back to topic: As far as I can see the the socket handling is still the only problem that prevents amuled to get compiled for Win32. Modifying wx' GSocket for Win32 isn't an easy task (at least for me). I only see two possible ways to solve the problem:
[list=1]
- When wxWidgets' socket classes have to be used, then a thread has to be created for every connection (at least for console applications - it's a different thing when creating a GUI application).
- Use the native socket functions only (with an additional WSAStartup/WSACleanup for Win32 (if required)).
[/list=1]
When you don't want to have a thread/connection then the only usable solution is solution #2 but this would also mean to completely avoid wxWidgets' socket classes.
Regards,
Mark
BTW: I'm developing software with wxWidgets since 7 years now and I know it (and its features) quite well.
