Faked Threads

BlitzMax Forums/BlitzMax Programming/Faked Threads

IceVAN(Posted 2008) [#1]
(my English is not very good. Sorry)

I do not know if someone happened to him, but the idea is as follows:

We can take advantage of our multitasking operating systems for making threads.

The idea is to launch applications from our main application, to make small/large tasks. Upload a huge file, Communicating with server, etc.

These applications can be invisible to the user if they are compiled without GUI

These applications can connect to the main application with our networking to localhost. Thus we have a channel of communication and streaming.

I am working on it and now works well with connections to a server Apache.
The main application can connect to the server without having stops where does this:

in=ReadStream("http::www.apacheserver.php")

In short I can see what I write.

bye!


ImaginaryHuman(Posted 2008) [#2]
I was thinking to do something similar but by launching processes for each module that I need to run as a separate task and then using some kind of networking to communicate between them.

My only concern is that networking has quite a bit of overhead. It's not really as efficient as inter-process-communication where you have a dedicated o/s-level API to use to get processes to send signals and stuff to each other, or even to share blocks of memory which would be more than ideal and much faster. If I have to compose a networking packet and send it to the networking system, even if it is a local IP address, it's still gotta think about it and route it and stuff like that, via the TCP stack, I would think? Not as efficient, but it would work.

Depends how responsive you want your system to be - but it would be a great solution for non-realtime interaction, working something like grid computing, where you give a chunk of processing to a local or remote computer over a network and have it crunch it and send back the results.

It is definitely faster being able to directly share the same data/memory space as in real threads, but if you don't mind the slight delays I think it's a good solution. It's better for both `programs` to be looking at and using the same memory directly, sharing it, rather than introducing a separation between the programs which ultimately requires a workaround in the form of something like a message to be sent and received and interpreted, or a packet to be sent through the networking system. Sharing is always more efficient than not sharing because separation always leads to overhead.


LAB[au](Posted 2008) [#3]
I used this idea but only in between 2 small console programs. It effectively enhanced speed on a Core Duo. The communication happened through network (BNetEx from Vertex, in UDP). The real gain comes from separating elements that take quite some time to return, like in my case comport reading/writing.


IceVAN(Posted 2008) [#4]
Let me use this idea for an online video game.

The game is a MMORPG but not style WOW. It's more a mix between WOW and TRAVIAN / OGAME.
It is not entirely in real time, and this system applies to me perfectly.

I can send and receive messages to the server without the game is jam (this is always very ugly) and although the response time is not very high, no matter, because there is no need for this type of games.

This is not an action game is a simulation / strategy game.