Feed aggregator

inc: allegro5: Remove _al_joydrv_directx declaration

fbc commits - Wed, 02/18/2015 - 12:00

inc: allegro5: Remove _al_joydrv_directx declaration
View Changes

DevBootstrap

wiki changes - Mon, 02/16/2015 - 07:00
2015-02-16 09:00:42 by DkLwikki - Swap steps 1 and 2

#770 ThreadCall does not ensure that data for passing parameter to a thread are still maintained until its launch

fbc bugs - Mon, 02/16/2015 - 06:26

Another malfunction with respect to the below extract of the ThreadCall documentation:

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

In fact, ThreadCall also refuses the subroutines with arguments like described above:
- unions
- user types containing unions, arrays, strings, or bitfields
but even if they are passed Byref !

Type UDT As String s End Type Sub thread (Byref u As UDT) End Sub Dim As UDT u Dim As Any Ptr p = Threadcall thread(u)

error 287: Unsupported function in 'Dim As Any Ptr p = Threadcall thread(u)'

For now, a workaround is to pass pointers Byval.

#770 ThreadCall does not ensure that data for passing parameter to a thread are still maintained until its launch

fbc bugs - Sun, 02/15/2015 - 21:23

Rewording of the analysis above:

First part of example with parameter passed by value:
- The data should be correctly incremented from 0 to 9 equi-distributed (not necessarily in the order) between 0 and 9 because a copy of each iterator data is passed by value.

DevBootstrap

wiki changes - Sun, 02/15/2015 - 14:46
2015-02-15 16:46:03 by DkLwikki - typo

ThreadCall does not ensure that data for passing parameter to a thread are still maintained until its launch

fbc bugs - Sun, 02/15/2015 - 13:38

General problem:
- When Threadcall involves to pass parameters to the thread, there is no guarentee that the corresponding data are still maintained after the end of the Threadcall statement and this until the thread is launched.
- In particular, object copies (as strings) must not be destructed before the thread is launched (for these, the fault may be more obvious than data that still may remain in memory even released).
- That may cause bad behavior.

A faults example for several passing types:

Dim Shared As Any Ptr m m = Mutexcreate() Dim As Any Ptr p(19) Dim As Integer K Sub threadByVal (Byval I As Integer) Mutexlock(m) Print @I, Str(I) Mutexunlock(m) End Sub Sub threadByRef (Byref I As Integer) Mutexlock(m) Print @I, Str(I) Mutexunlock(m) End Sub Print "Adress", "Data value" Print For I As Integer = 0 To 9 p(I) = Threadcall threadByVal(I) Next I For I As Integer = 0 To 9 Threadwait(p(I)) Next I Print For K = 10 To 19 p(K) = Threadcall threadByRef(K) Next K For I As Integer = 10 To 19 Threadwait(p(I)) Next I Mutexdestroy(m) Sleep

Output:

Adress Data value 10485420 1 11533996 3 13631148 4 15728300 7 16776876 1 18874028 1 12582572 1 14679724 2 10485420 2 17825452 2 1244800 13 1244800 18 1244800 20 1244800 20 11 Appuyez sur une touche pour continuer...

First part of example with parameter passed by value:
- The data should be correctly incremented from 0 to 9 because a copy of each iterator data is passed by value.

Second part of example with parameter passed by reference:
- The fault is not the rapid incrementation of the displayed data of the iterator because it is passed by reference (there is no temporary variables involved by ThreadCall) and each value is not frozen until the thread is launched.
- But the address of the reference should be maintained until the thread is launched, instead of, a wrong address value is passed to the thread ('11' instead of '1244800' in the above example), then the program crashes when it tries to access it.

Referring at forum, from the post:
http://www.freebasic.net/forum/viewtopic.php?p=205239#p205239

KeyPgThreadCall

wiki changes - Sun, 02/15/2015 - 01:18
2015-02-15 03:18:59 by FxMwikki - Generalized the warning sentence about any type of passed parameter

#769 sub routine does not recursive when select static

fbc bugs - Sat, 02/14/2015 - 14:41
  • status: open --> invalid

KeyPgThreadCall

wiki changes - Sat, 02/14/2015 - 13:17
2015-02-14 15:17:22 by FxMwikki - Added warning about the present design

rtlib: Fix broken FB_LOCK() code in fb_IsRedirected()

fbc commits - Wed, 02/11/2015 - 23:29

rtlib: Fix broken FB_LOCK() code in fb_IsRedirected()
View Changes

KeyPgMutexCreate

wiki changes - Mon, 02/09/2015 - 09:51
2015-02-09 11:51:01 by FxMwikki - Only added an adjective and deleted a comma, but useful for understanding!

fixed potential memory leaks

fbc commits - Fri, 02/06/2015 - 19:47

fixed potential memory leaks
View Changes

Merge pull request #17 from thrimbor/fixes

fbc commits - Fri, 02/06/2015 - 19:47

Merge pull request #17 from thrimbor/fixes
View Changes

SSE emitter: Fix potential ICE if certain float constants exist

fbc commits - Thu, 02/05/2015 - 12:55

SSE emitter: Fix potential ICE if certain float constants exist
View Changes

#769 sub routine does not recursive when select static

fbc bugs - Wed, 02/04/2015 - 08:24

This behavior seems to be normal:
When a procedure is declared as static, all the local variables of the procedure become static including the variables in sub scopes, and therefore the iterator j in the for loop.

Example:

sub test () static dim as integer i i += 1 scope dim as integer j = 10 j += 1 print i, j end scope end sub test() test() test() sleep

Output:

1 11 2 12 3 13

sub routine does not recursive when select static

fbc bugs - Tue, 02/03/2015 - 18:42

Ticket 769 has been modified: sub routine does not recursive when select static
Edited By: dkl (dkls)
Status updated: u'open' => u'invalid'

sub routine does not recursive when select static

fbc bugs - Tue, 02/03/2015 - 18:42

dim as ushort dm,i,j,k,nit
sub subrec(byval i as integer)
dim j as ushort
for j=i to 6
print j
subrec(j+1)
next j
end sub
subrec(2)
end

now the above enters recursively and get the correct output as expected - could leave off the byval or even put byref and still all is ok BUT if add the 'static' option as in

sub subrec(byval i as integer) static

then it ignores the recursive calling of itself - ignores the 'subrec(j+1)' statement while it should not - regardless of the ' static ' option which should have no effect on it.

#768 View [Screen] doesn't clip to screen properly

fbc bugs - Mon, 02/02/2015 - 13:04
  • status: open --> closed
  • assigned_to: dkl

#768 View [Screen] doesn't clip to screen properly

fbc bugs - Mon, 02/02/2015 - 13:04

Committed now as [54d999]

rtlib/gfxlib2: Ensure to clean-up gfxlib2 before rtlib

fbc commits - Mon, 02/02/2015 - 13:03

rtlib/gfxlib2: Ensure to clean-up gfxlib2 before rtlib
View Changes

Pages

Subscribe to FreeBASIC Programming Language aggregator