Strange error reporting with threadcall

[SARG]

Code: Select all

function procf()as any ptr
	return @procf
end function

'sub procs()  ''<-------- Uncomment the 2 lines
'end sub

dim as integer ptr aaa
aaa=threadcall procf
aaa=threadcall procf

With commented sub procs lines --> 2 error messages
FbTemp.bas(9) error 289: Expected sub, found 'procf' in 'aaa=threadcall procf'
FbTemp.bas(10) error 289: Expected sub, found 'procf' in 'aaa=threadcall procf'

When uncommenting sub procs lines --> only 1 error message
FbTemp.bas(10) error 289: Expected sub, found 'procf' in 'aaa=threadcall procf'

[MrSwiss]

Well, the only 'alowed' procedure type for a thread is a SUB, according to the docs.
(the only alowed parameter is a Any Ptr, to further complicate matters)

Therefore, I fail to see what you call 'strange'.

[fxm]

This is just a quirk compared to the more important fact that ThreadCall is currently not safe, and therefore is currently strongly discouraged for use (see documentation):

WARNING: Presently when Threadcall involves to pass parameters to the thread, there is no guarantee that the corresponding data are still maintained after the end of the Threadcall statement and this until the thread is launched. That can cause bad behavior.
Therefore it is more advisable for the moment to use ThreadCreate (100% safe) instead.

[fxm]

(the only alowed parameter is a Any Ptr, to further complicate matters)

Not exactly for ThreadCall (seen by the user):

While most subroutines are supported, the following types of subroutines may not be called:
- Subroutines using Variable Arguments.
- Subroutines with unions which are passed as arguments.
- Subroutines with user types containing unions, arrays, strings, or bitfields which are passed as arguments.

[SARG]

Well, the only 'alowed' procedure type for a thread is a SUB, according to the docs.
(the only alowed parameter is a Any Ptr, to further complicate matters)

I know that and I knew that someone will do this remark :-)

Therefore, I fail to see what you call 'strange'.

What is strange : uncommenting the two lines (not related in any way with threadcall) you only get one error message.....

[MrSwiss]

The fact remains that, as soon as the first 'coding error' has been made:
the following 'error messages' are at times 'misleading'.
Because of that 'erratic' compiler behavior, I typically dismiss then entirely.

First message states: SUB expected ... (which seals the deal, so to speak).

[SARG]

This is just a quirk compared to the more important fact that ThreadCall is currently not safe, and therefore is currently strongly discouraged for use (see documentation):

WARNING: Presently when Threadcall involves to pass parameters to the thread, there is no guarantee that the corresponding data are still maintained after the end of the Threadcall statement and this until the thread is launched. That can cause bad behavior.
Therefore it is more advisable for the moment to use ThreadCreate (100% safe) instead.

There are some tests for Threadcall in test suite. And when running it for gas64 I'm facing an issue so for now I'm just searching to know why and I try different things.

The fact remains that, as soon as the first 'coding error' has been made:
the following 'error messages' are at times 'misleading'.
Because of that 'erratic' compiler behavior, I typically dismiss then entirely.

@Mrswiss You will never change......

Ok. But when there is a sub you get only ONE error on the SECOND threadcall while the first one, exactly the same, seems correct. As an user what could you think ?

I report a case but maybe there are others bugs related to threadcall that could also mislead users.

[MrSwiss]

@Mrswiss You will never change......

Why on earth should I change a very successful strategy of 'debugging' code???
It's logical, as well as practically oriented pragmatism.
Doing things in a step by step way (major problem first). "et voila" all the minors have vanished, too.
(not necessarily always, but many, many times)

[fxm]

About the ThreadCall documentation page

It's amazing that nobody paid attention to it, but the example itself from the documentation page shows that the operating of ThreadCall is bugged if we look at the 'id' string parameter which is destroyed before being displayed by the thread.

In contrast, this simple variant (id As String Zstring) seems to work correctly:

Code: Select all

'' Threading using "ThreadCall"

Sub thread( id As Zstring, tlock As Any Ptr, count As Integer )
    For i As Integer = 1 To count
        MutexLock tlock
        Print "thread " & id;
        Locate , 20
        Print i & "/" & count
        MutexUnlock tlock
    Next
End Sub

Dim tlock As Any Ptr = MutexCreate()
Dim a As Any Ptr = ThreadCall thread("A", tlock, 6)
Dim b As Any Ptr = ThreadCall thread("B", tlock, 4)
ThreadWait a
ThreadWait b
MutexDestroy tlock
Print "All done (and without Dim Shared!)"

[fxm]

It's amazing that nobody paid attention to it, but the example itself from the documentation page shows that the operating of ThreadCall is bugged if we look at the 'id' string parameter which is destroyed before being displayed by the thread.

The following explains this above:

Regarding temporary strings, there was a change in 1.00.0. Previously, the temp strings were leaked, and since 1.00.0 they're freed at the end of the ThreadCall statement (this commit). So temp strings were working before, by beaing leaked (which isn't exactly good though).

However, overall the same problem exists for temp UDT objects. Their behaviour didn't change (they were not "working" before like temp strings). That was the reason why I decided to make that change for temp strings.

[coderJeff]

With commented sub procs lines --> 2 error messages
...
When uncommenting sub procs lines --> only 1 error message

That bug was tough to find though seems obvious now. parser-quirk-thread.bas:cThreadCallFunc() was using a wrong function to check if the procedure has a return type and was referring to invalid memory through a wrong pointer.