TCP Server multi-threading (New topic)

[Scott Turchin]

Thanks John - so back to my original using globals such as the socket - it's still failing on the TCP NOTIFY.

This is the modeless dialog message pump..

Select Case CbMsg
    Case %WM_INITDIALOG
        Dialog Show State CbHndl, %SW_HIDE 'hide the window from flashing up
        SetTimer CbHndl, %IDT_TIMER2, 10000, ByVal %NULL
        hTcp = %INVALID_SOCKET
        hTcp = FreeFile
        Tcp Accept g_ntcpSocket As hTcp 'Debug shows #9 here
        Tcp Notify #hTcp, Accept Connect Recv Close  To CbHndl As %TCP_HTML
'        Tcp Notify #hTcp, Recv Close To CbHndl As %TCP_HTML      



'xxxxxxxxxxxxxxxxxx

Never gets to this point:

xxxxxxxxxxxxxxxxxxxxx


    Case %TCP_HTML
        Select Case Lo(Word, CbLParam)
            Case %FD_READ
                If hTcp <> %INVALID_SOCKET Then

[John Petty]

Michael

I'm not a DDT guy

Sorry I didn’t realise that, I thought everything GUI was you strength, specially seeing you have been making such positive assertions on the subject, whereas PB DDT has handled my simple needs.
As such I have to rely on the Power Basic Manual which says

A modeless dialog must always have a message pump running while the dialog is running. Without a message pump, a modeless dialog will not be able to receive messages to redraw itself, etc.

Which just might explain why his callback function is never receiving the RECV message.

…. the function will end. The window will still exist,

Honestly I don’t know how PB DDT handles that in all cases but assume without any proof that seeing the thread will end with the End Function statement as shown in my prior post that PB as part of cleaning up after the thread closes will include closing the Dialog.
Immediately after calling the thread create function Scott does a Thread Close so the handle will be invalidated, the thread will have ended etc. so though his statement

Determined my thread is closing before anything can happen

Might not by your standards be semantically correct I guess it actually is.
Your latest “next step” example fascinates me but leaves me a little confused

ONE window can handle ALL current "connect and send" sessions

TCP NOTIFY RECV only allows you to give one message number so how does the re-entrant callback which now has a single CBHNDL and a single message number know which of the multiple current connections it is dealing with using either Globals or the Stack.
John

[Michael Mattias]

>This is the modeless dialog message pump..

Typo or stray comment?

Message loop =

DO 
  DIALOG DOEVENTS
LOOP

or 
WHILE GetMessage( 
    IF ISFALSE IsDlgMessage (
         TranslateMessage
         DispatchMessage

(You do have this in your program somewhere? If not, that explains why you never get to where you want to go).

MCM

[John Petty]

Scott
You posted while I was writing the last reply (am a slow typist, won't comment on my thinking speed with my age).
First step, just change your thread dialog to MODAL, PB will now provide the message pump and this statement

Dialog End CbHndl,%TRUE

which you already have in the correct place will close the dialog and end the correct thread as each thread will have a different CBHNDL.
You may have other issues with different options per user but this should be a good first step.
John

[John Petty]

>
(You do have this in your program somewhere? If not, that explains why you never get to where you want to go).

MCM

I thought you read his code, so what was this all about

If I weren't just one hell of a nice guy, I'd suggest that your statement "his first simple and understandable problem is so hard for you to understand," constitutes a personal insult, which is not permitted here. But I can be be quite understanding when it's apparent English is not your first language.

My first language is English, my second American. Do I now get an apology from the great guru?
John

[Scott Turchin]

OK I did NOT have this in my Thread -

DO
DIALOG DOEVENTS
LOOP

So that solves that and it works, but it takes like 4 OR 5 seconds for the thread to fire up now, and for the image or html page to be displayed - hardly worth it in my opinion, especially if I get 50-100 concurrent connections (Not likely but hey...)

FAR FAR faster just having all of that in my message pump for my callback function
So forget the server thread - but I will take all the advice you've given on my Globals and get those into a TYPE.........


So......Globals aside - I'm working on that, I'm not sure this is going to work....

So I was under the assumption that DDT with MODELESS dialog boxes would also suspend like a Modal does...not so....

This is entirely too slow...

'============================================<tcpThreadProc>===============================================================
Function CreateNewConnectionThread(ByVal tcpCount As Long) As Long
Static hThread   As Long
Local lResult As Long
Thread Create ConnectionThreadProc(ByVal tcpCount) To hThread
WaitForSingleObject  hThread,10000
Function = hThread 'grab thread handle to close prematurely and properly if need be.
End Function
'==========================================================================================
Function ConnectionThreadProc(ByVal tcpCount As Long) As Long 'Creates a modeless dialog box in a new thread so to avoid locking up main app.
Local tDlg As Long
Local lResult As Long
Dialog New 0, "",,, 1,1, To tDlg 'modeless
Dialog Show Modeless tDlg Call ConnectProc To lResult
Do While IsFalse lResult
  Dialog DoEvents
Loop
Function = lResult
End Function
'==========================================================================================
CallBack Function ConnectProc() As Long

[John Petty]

Scott
In 8.04 Dialog Doevents has a problem, do a search.
John