How to achieve true 100% multi-threading in VB. OLD THREAD

U return the result in a UDT. That's what I do in my example. I send the file details to the client UI using a UDT. However, you could replace this with a property bag, since it's a byte array and you know it's memory address and length. U could send these details in the Send/PostMessage API.
To reduce the files you could place the class code for the thread procy in the main app. But 2 apps in the min. Client and ActiveX thread...

Does that help?

Woka

So where's the latest and greatest non buggy version?
Someone post it please.

Jon

A new an improved demo is in the pipe line.
Should be done by either tonight, or tomorrow.
The new version will be a winsock demo.

It will allow you to start a session:

VB Code:

Dim objSession As SvrSession
   Set objSession  = New SvrSession
   objSession.Start [Port], [DLL Name], [Class Name], [Method]

This server side DLL handles winsock connects automatically, each of which runs in a different thread.
The reason you can pass in a DLL, Class and Method name is so that if the command set between the client winsock objects and svr winsock objects, is not an internal one then you can pass the data sent onto another DLL, which is relevant to your app.
This allows you to use the same winsock objects in many many different applications without have to code each one individually.

So I could have 2 apps using the same winsock code...One app will have:

VB Code:

Private objSession As SvrSession
 
Private Sub Form_Load()   
   Set objSession  = New SvrSession
   objSession.Start 40000, "MyDLLName", "clsData", "ProcessData"
End Sub

and the other app simply has:

VB Code:

Private objSession As SvrSession
 
Private Sub Form_Load()   
   Set objSession  = New SvrSession
   objSession.Start 40500, "AnotherApp", "clsMyData", "DealWithData"
End Sub

Connects will be able to be viewed and destroyed VIA the client side :D

I am almost there...just jigging my code and trying to get it as neat as possible.

Oh, and the winsock runs syncronosly...this means that when your client sends data it does not get control back UNTIL the server has processed the data and has sent a response back to the client. This is one thing normal winsock control doesn't do.

Any other functionality you may want to see in this?

Woka

Quote:

---

Any other functionality you may want to see in this?

Woka [/B]

---

Yes have it wipe my a**:bigyello:

Here's is the new tool I have been working on :)

http://www.vbforums.com/showthread.p...hreadid=286613

Let me know what you think.

This will aid multithreading applications no end.
Will try and add this tool into the file searching example I wrote earlier. The code will be dramatically reduced due to this new DLL.

Woka

hi woka

Quote:

---

To Woka:
remember me, i'm the fellow who's struggling to deny the very
unacceptable fact of vb's inability to thread and vow to create
a dll that provides threading services?

since the last time i posted here, i did some lil' research on
threading. But then I abandoned it and continue with my p2p
networking and dx raycasting engine projects.

Your method works pretty good, using PostMessage to place
messages on queue, which the thread will retrieve sooner or l8er,
without u waiting for it and continue with ur execution. **I salute
u, Genius!**

Thinking back, i seem to understand somethin'. U mentioned it's
impossible to call subs unless pre-defined, which ultimately
requires u to rewrite the thread proxy althogether from scratch
for each different project, rite? Since u perform things not based
on sub calling, but recognizing messages and do things
accordingly, which is pretty limited really.

---

In the end, I know it's not quite possible to make a dll out of this.
Like i posted earlier, I want to understand how and why it fails.
But how about this?
With some speed trade off, we could use CallByName to make
hell a paradise, how's that? Different Messages for different
functions is too spagetthi.
well u probably have thought about it earlier as well as with its
pros and cons(more cons actually maybe) but letme try it out.
i'm quite n00b in stuffs like this.

Don't quite see what you mean about the CallByName function :(

Here's a newer more uptodate multithreading DLL. This version is SOOOO much simpler than the 1st one I posted here :)

http://www.vbforums.com/showthread.p...hreadid=288289

WOka

Conventionally, if we're to use apartment threading, we've to use
ActiveX exe, rite?
To create a thread, we've to use CreateObject. New keyword
doesn't work here. Unfortunately, another thread including the
parent is created in another memory workspace.

So, when I said I wanted to turn it into a DLL, so that it makes
threading easier since it's managed as an object, u said it might
not be possible.

Well, based on above points, it's either I dont understand ur code
enough(perhaps I need ur further explanation), or it's weird that
ur ThreadProxy is a DLL, whereas the object u are threading is an
ActiveX exe. Confuse me enough. Or probably it's the
MyThread exe that's threading it and ThreadProxy just create
ThreadObject for MyThread to thread it?

My naive idea is like this:
We've a DLL which has a Threader object, of which under it's
hierachy is a ThreadProxy object. ThreadProxy creates a window,
wnd1. Under ThreadProxy is another ThreadObject with a
created window, wnd2. Say, If we want to thread "Wscript.Shell"
object, ThreadProxy will CreateObject out of it, and pass it
to ThreadObject(or ThreadObject create itself?).

From the container which contains this DLL, we issue a command
like 'Wscript.Run', then we pass this along to ThreadProxy.
ThreadProxy creates a UDT containing the command and
parameters, then POST a message to wnd2. Wnd2 gets it and get
the UDT's mem address as well. Then ThreadObject gets the UDT
and through "CallByName', it calls the command as contained in
the UDT.

You are right.
The reason my 1st demo had a thread proxy DLL, was to split this away from the UI.
This means if I wanted to use the file searching in another app, I just referenced the DLL.
The code for this DLL could have easily have been in the UI it'self.

The version you are describing there is an old out of date one.
If you look at the code I posted in the link in my last post you will see how much the code has changed. Easier to undersatand, and more generic.
There are 2 examples with that post.
One allows 2 normal EXE's to communicate together, and the other uses an activeX EXE multithreading file searching example, like the one in my 1st version.

Let me know if you have any questions.

Woka

No, sometimes old things teaches new things.
Your old code has less things to do (Just adding numbers),
therefore the code might not be as clutter as the new one.

Anyhow, i'll look at that one.

Threading is provided to us already by VB through ActiveX exe.

But your method is to allow us to return from a function as soon
as we call it while letting it busy on its own? Which we couldn't
possibly do in VB eventhough threading is provided?

Remember the SetTimer I once said? I said it was from a code of
mine that I unknowingly uses multithreading, delusioning me that
SetTimer making some charms.

Now thinking back, why don't we put a Timer on the new thread?
It might check on a queue data structure to check if there's any
functions need to be called along with their parameters. With
Timer, we don't have to wait for return.

Have you actually looked at my code?
Why on earth would you want a timer in the ActiveX EXE.
I have a subclassed window that looks for messages.

VB does allow you to create threads, but what it doesn't allow you to do is to access the thread while it's processing.

I VERY VERY VERY cheap nasty hack is to use a timer on a form in the active X EXE. You can a function that stores a value to let the app know which function has been called, and then the timer is enabled. The user interface returns from the ActievX EXE and continues running. The ActiveX EXE timer fires and NOW the function is called properly and the ACtiveX EXE starts works. Very crappy way :( The UI and the Active XE exe CANNOT communicate with each other now :(

That's probably how your timer was used. This is the cheap hacked way of doing it, and I would never use that.

My old code IS MORE cluttered. It didn't just ADD 2 numbers together? What? I don't understand? Or are you talking about a VERY VERY VERY old example?! The examples posted here are file search examples where you can start many searches that all run in their own threads. These examples pass large data structures back and forth, and are slightly better than a thing that just adds numbers.

Woka

yea precisely, and I understand ur app well.
And yea, it's an old example, but I did look at that new one, too.

Quote:

---

VB does allow you to create threads, but what it doesn't allow you to do is to access the thread while it's processing.

---

well, does this apply to your method?

U mean, as the thread gets the message from wndproc and
processes it, u can't access it, but in what way u can't access it?
Its members, its props?
In ur example, not even ThreadProxy could access its props if it
wants asynchronousness, which led u to use PostMessage.

And why u can't communicate during that interval? Dont
understand.

I've done one, using ur method, and gosh it worked too well :)

And ur method of changing a datum directly to another type
through udt LSETting is really gr8.

You are still refering to an old example.
The new example doesn't use UDT's :)

There is a link in one of my posts about 5 up from this post. That's the new version. No ThreadProxys, no UDT's, no adding 2 numbers together.

Right OK, added to this post is an example of multi threading, but not a good one. This shows you the problems that my method over comes.

Copy the thread Active X EXE.
Open the UI project, reference the thread active X EXE, and compile.
Now run.
You will notice that when you click on "Get Bagder" button it gets and displays a property from the active X EXE.
Now start the loop in the thread, which uses the timer method.
While this is looping, start the loop in the UI. This demos that they are in fact running in different threads.
Now the problem arrises :(
Start the thread looping again, and now try and click the "Get Badger" button. You UI will hang. if you try and move or click on the UI app you get that stupid "Switch To" error. This function WILL NOT succeed UNTIL the thread has finished looping.
So if the get Badger button was in fact a cancel button then this would not work.

Does that make things clearer?

Woka

From what u say, I guess I know what you're saying.
But this shouldn't be VB's limitation, it's natural to think that we
can't access the thread because it's processing things in tight
loop. Which means other languages behave such as well.

I'll check them out.:)

This IS VB's limitaion :(
Which is why I wrote my multithreading DLL. This gets around this problem by using some complex coding and memory manipulation. You think I wrote that code for a laugh? Not a chance...that code is ALL needed I am afraid.
VB does not handle multithreading. This has to be coded in, like I have done.

Other languages handle things differently. Maybe C++ uses a method like mine, but it's automatically coded into C++ and all you need to do is the following:

Code:

---

Call StartThread(objMyObject)

---

I just don't know.

Woka

But the thread is running in a tight loop! Which means the
instruction pointer is lingering around there. Any other thread that
access it would require the instruction pointer to shift to where it's
needed now by the other thread. Then the loop would halt, albeit
temporarily.

Unless......the other thread jumps into this thread to run the
function it wants, like a thread running into another thread(very
unlikely), or a DoEvents is put in the loop.

Can you show me another multithreading example(that badger
one) which correct this problem? I just need something simple so
we can all see where and how it works.

Or you can point it to me in your existing examples.

Woka, the code you last posted would communicate fine if you put a DoEvents in each loop. Are you unwilling to do that because it's expensive, or some other reason?

You are correct. It would.

But the DoEvents also affects your app in many different ways.

VB Code:

Option Explicit
 
Private Sub Command1_Click()
Dim lngIndex As Long
    For lngIndex = 1 To 30000
        Me.Caption = CStr(lngIndex)
        DoEvents
    Next lngIndex
End Sub

Create a new EXE with a command button on Form1, and add the above code.
While the code is running try closing the app down, or clicking on the button again.
Yea, yea...I know you can code round this by doing:

VB Code:

Option Explicit
 
Private mblnCancel  As Boolean
 
Private Sub Command1_Click()
Dim lngIndex As Long
    For lngIndex = 1 To 30000
        Me.Caption = CStr(lngIndex)
        DoEvents
        If mblnCancel Then
            Exit For
        End If
    Next lngIndex
End Sub
 
Private Sub Form_Unload(Cancel As Integer)
    mblnCancel = True
End Sub

But this is just one tiny problem. What if a user clicks on a menu or something else, you then have to handle that.
I don't like DoEvents in a loop. It causes more problems than it's worth, and is considered a cheap hack.

This means you would have to add DoEvents in your main app too since what if your main app is doing something when the thread tries to contact it? You are now opening a HUGE can or worms :(

Admittedly I am using DoEvents in my file searching demo thread, but this will be replaced with a PeekMessage subroutine, that just allows the MultiThreading DLL window to process it's messages.

With my filesearching app, if It was done how you have mentioned, then when a file was found the thread would call the main app, which in turn would update it's main grid. The searching of files is halted at this point until the code execution is returned to the thread...right? Now if you have many file saerches running then this will dramatically affect the performance of your threads :(
Since my method uses the Postmessage function the code execution returns straight back to the file searching so it can continue searching, even though the main app hasn't processed the msg yet.

Does that make sense?

Woka

Yes, mostly, but

Quote:

---

This means you would have to add DoEvents in your main app too since what if your main app is doing something when the thread tries to contact it?

---

The main app should be responsive to user input anyway, so it will not likely be doing tasks that take a long time (that's what the worker thread(s) are for!).

Obviously the main app does do some things, and if the worker tries to contact the app while it's doing something, the worker will block, as you mention. I'd just point out that the blocking time should be minimal, for the above reason.

I agree about the file search example. Messages and memory access rather than blocking COM method calls is the way to go if you need to transfer data from thread to thread while maintaining performance.

I hate COM.

Oh, brilliant, PeekMessage.
So we could abandon wndproc?

Without COM, things will get unorganised and cannot be reused.
We've to write from scratch for every project that uses threading.

Errr...yes, and no. I would only PeekMessage while I was looping in a long loop since the Msg won't get pushed through until the loop is completed or I use DoEvents.
I did have a thought about using API WaitMessage, but that would hang the thread, which isn't good if yo want to click on a menu or something :(
I feel the WndProc is here to stay. What's the problem with using it anyways?
My code IS reusable. You wouldn't have to write multithreading code over and over again. You would just use the vbGateway2 DLL which I posted a few posts above. Is that the project you are looking at?
The vbGateway2 DLL is a threading go-between for your main app and an activeX EXE.

Luv and hugs.

WOka

Quote:

---

Without COM, things will get unorganised and cannot be reused.

---

COM is not necessary for code reuse, it merely helps. My complaint about COM is it makes things that should be simple, cryptic and over-complicated. VB6 is so closely tied to COM that you can't not use it anyway.