1. listen (sock, back)
- Posted by FredRansom Mar 24, 2010
- 1191 views
When listen (sock, back) is active, existing communications sockets cannot work because there is no cpu time for them. Only one connection can be permitted.
Euphoria 4, MS Window Vista, win32lib, EU 4 sockets
Multitasking is used throughout.
2. Re: listen (sock, back)
- Posted by jimcbrown (admin) Mar 24, 2010
- 1278 views
When listen (sock, back) is active, existing communications sockets cannot work because there is no cpu time for them. Only one connection can be permitted.
Euphoria 4, MS Window Vista, win32lib, EU 4 sockets
Multitasking is used throughout.
This is a known limitation of the tasking system. In 4.0 we now use threads, but there is a big global lock so nearly all of the time only one thread is allowed to run. (On Unix (including Mac OS X) this issue is easily worked around by using fork() instead of tasks.)
3. Re: listen (sock, back)
- Posted by FredRansom Mar 25, 2010
- 1239 views
I'm not familiar with threads in EU 4. Is their any documentation for them? Threads work fine in VB, C#, and C, so perhaps I can tweak the OS thread prioritization.
4. Re: listen (sock, back)
- Posted by mattlewis (admin) Mar 25, 2010
- 1212 views
I'm not familiar with threads in EU 4. Is their any documentation for them? Threads work fine in VB, C#, and C, so perhaps I can tweak the OS thread prioritization.
Euphoria code does not use native threads. For non-Windows implementations of euphoria's multi-tasking system, pthreads were used to implement them. The windows implementation was done with fibers, which provide native cooperative multitasking.
The original method of switching between stacks didn't work with (at least) newer Linux kernels. I think that some anti-stack smashing features were responsible for the breakage.
Basically, we use threads and mutexes to ensure that only one task runs at any time.
As for using native threads with a euphoria program...there are issues with the euphoria back end that would currently prevent this from working. I suppose it might be possible to hack up some translated code that could be threaded, but even then, the runtime libraries aren't thread safe. I couldn't say if this will ever change.
Matt
5. Re: listen (sock, back)
- Posted by ghaberek (admin) Mar 27, 2010
- 1206 views
Curious, can't you use select() to determine if a connection is waiting? Or is that just for read()?
It's been a while since I've used TCP. 
-Greg
6. Re: listen (sock, back)
- Posted by m_sabal Mar 27, 2010
- 1075 views
The preferred command is poll. Just about every socket command has a blocking and non-blocking version that are named differently. Reviewing the documentation should help you find what you are looking for.
7. Re: listen (sock, back)
- Posted by FredRansom Mar 27, 2010
- 1087 views
Didn't fine poll in the EU 4 documentation. Basically, right now it looks like either writing a dll in some other language or just not using EU 4 for server work. Also, client mode fails to act unless its window is in focus. Right now it appears that EU 4 is unsuitable for general tcp/ip use. Please let me know if there is a better way within EU 4.
8. Re: listen (sock, back)
- Posted by jimcbrown (admin) Mar 27, 2010
- 1085 views
Didn't fine poll in the EU 4 documentation. Basically, right now it looks like either writing a dll in some other language or just not using EU 4 for server work. Also, client mode fails to act unless its window is in focus. Right now it appears that EU 4 is unsuitable for general tcp/ip use. Please let me know if there is a better way within EU 4.
I've only worked with the Unix version of Eu 4 and sockets. Still, this behavior seems strange. poll() does not exist in Eu 4, but the Unix version of select() can be made nonblocking (this is controlled by the timeout parameter). Under Unix, listen() is nonblocking and does not wait at all. accept() is blocking, but with select() one can call accept() only when it is known that a connection is waiting to be made (such that accept() returns right away). The sockets code just uses winsock, so these are winsock oddities, bugs in the wrapper that Watcom C uses for winsock, or something very strange is going on here.
9. Re: listen (sock, back)
- Posted by FredRansom Mar 28, 2010
- 1036 views
On MS Windows, using win32lib, listen does not return until it receives an incoming connection request.
10. Re: listen (sock, back)
- Posted by jimcbrown (admin) Mar 28, 2010
- 1062 views
On MS Windows, using win32lib, listen does not return until it receives an incoming connection request.
I didn't realize that win32lib had its own tcp/ip functions.
I recommend trying the functions in std/socket.e - you might have better luck with these.
11. Re: listen (sock, back)
- Posted by jeremy (admin) Mar 28, 2010
- 1004 views
Look at demo/chat_server.ex ... It is a multi-user chat server that accepts any number of connections all while maintaining communication with other connected clients. Basically, the main loop uses select to detect new incoming connections, incoming messages or clients that have disconnected. When a new connection exists, it calls accept and let's the other chatters know of the new person who just joined. When a new message comes in, the message is then sent to all connected clients. When a client disconnects, all remaining clients are sent a disconnect notice.
You can use chat_client.ex to communicate with the server. The idea was not to make a chat system but to show off select.
Maybe this is what you are looking for?
Jeremy
12. Re: listen (sock, back)
- Posted by FredRansom Mar 28, 2010
- 1054 views
Yes, this is what I needed. I also came across a library that implements Windows asynchronous sockets directly.
The reason I want to use Euphoria in my particular application is that, although .net is twice as fast in straight number crunching, EU is 3 to 4 times as fast as .net when dealing with complex hierarchical data structures in spite of .net's arraylist that simulates EU sequences.
Thank you for your replies.
13. Re: listen (sock, back)
- Posted by DerekParnell (admin) Mar 29, 2010
- 1022 views
On MS Windows, using win32lib, listen does not return until it receives an incoming connection request.
I didn't realize that win32lib had its own tcp/ip functions.
Win32lib does not have any TCP/IP functions in it.
