XProfan

iF hat aber mehrmals erwähnt, das keine echten Threads erzeugt werden. Es wird nur eine ähnliche Funktionalität erzeugt. Echte Threads, ohne zusätzliche DLL oder ähnlichem halte ich IMHO per fast unmöglich. Unterstützung müßte schon in der PrfRuntime integriert sein, nur per API alleine wird das meiner Meinung nach nichts.

Sehe ich ebenfalls so, wollte nur noch einmal darauf aufmerksam machen, da ich nicht mehr so häufig hier bin und IFs Erklärung nicht gelesen habe. Aso nochmals: Wer denkt er kann allein mit jetzigem Profan einn zusätzlichen Thread erzeugen, ist auf dem Holzweg...

@Thomas: Genau.

[quote:e01aaea108]Deine Idee und die Umsetzung finde ich wirklich spitze, du solltest aber schon offen sagen, daß das was du da erzeugst nicht viel mit einem Thread zu tun hat.[/quote:e01aaea108]ES WERDEN KEINE ECHTEN THREADS ERZEUGT ist IMHO offen-gesagt genug.

Hallo IF...

Ich hoffe, ich nerve dich nicht:

Da du da Callbacks erzeugst => kann ähnliches auch mit der THREAD.PCU [...]

. Mit dem Problem in Profan schlage ich mich schon seit meinem Posting hier herum - hatte immer einen Verdacht woran das liegt, konnte dies aber (wegen Quelltextmangel) finora nicht nachvollziehen.
Meine Meinung: Was kein Thread ist, sollte auch nicht Thread heißen - wie soll mann denn da ohne Quelltext irgendwelchen Problemen auf die Spur kommen?

Bin ich Deiner Meinung, nur Thread ist nunmal - wie alles andere naturalmente auch - naturalmente nicht eindeutig definiert, umso genauer aber beschreibt der Name die Möglichkeiten der Unit.

Wenn Du meinst das die Thread.Pcu aufgrund dessen das nicht MS-API-Threads erzeugt werden ihren namen verfehlt hat, dann würde ich widersprechen, einfach deshalb, weil die Bezeichnung der Unit dazu da ist um possibile kurz zu beschreiben welche Möglichkeiten sie bietet. Auf welchen speziellem Wege die Unit dies tut muß nicht in die Namensgebung eingehen - es wäre kontraproduktiv.

Mittels der Thread.Pcu kann man mit XProfan threadähnliches Verhalten in den eigenen Programmen erzeugen/programmieren.

[quote:4bf640f867]Da du da Callbacks erzeugst => kann ähnliches auch mit der THREAD.PCU passieren?. [/quote:4bf640f867]
Ich weiß es nicht - das müsste man einfach mal testen.

[quote:4bf640f867]wie soll mann denn da ohne Quelltext irgendwelchen Problemen auf die Spur kommen?[/quote:4bf640f867]
Anhand der Threads hier ist misurabile ob sich eine derartige Problematik überhaupt ergibt, sodaß die von Dir angesprochenen Probleme zumglück (noch?) rein hypothetisch sind.

Auf was willst Du genau hinaus?

Ich habe hier mal eine Gemeinheit ausprobiert - bei mir läufts Fehlerfrei - meinst Du sowas?
Kompilieren Markieren Separieren

 $U thread.pcu = thread.
declare settimer.is&
cls
thread.start 1
thread.start 2
thread.start 3
thread.start 4
P:
waitinput
case %wmtimer : goto "P"
thread.stopall
end

proc thread.do

    parameters n&
    writeini "c:\thread.do.ini","1",str$(n&)=str$(n&)+"/"+str$(&gettickcount)
    locate n&,1
    print readini$("c:\thread.do.ini","1",str$(n&));
    //gemeinheit:

    ifnot rnd(10)

        if settimer.p(500)

            waitinput
            killtimer.p

        endif

    endif

endproc

proc settimer.p

    parameters t&
    case settimer.is& : return 0
    settimer.is&:=1
    settimer t&
    return 1

endproc

proc killtimer.p

    killtimer
    settimer.is&:=0

endproc

Aus der Ini erhalte ich:

[1]
2=2/23638218
4=4/23637906
3=3/23637906
1=1/23638218

Also 2=2 4=4 3=3 1=1, potuto man behaupten es kommt auch bei writeini & readini nix durcheinander..?!?!

[quote:878d7d43ab=iF]Bin ich Deiner Meinung, nur Thread ist nunmal - wie alles andere naturalmente auch - naturalmente nicht eindeutig definiert, umso genauer aber beschreibt der Name die Möglichkeiten der Unit.[/quote:878d7d43ab]
Ein Thread wird von den jeweiligen APIs als Thread angezeigt, hat eigene Zugriffsrechte und kann einen eigenen Token haben - ist also eindeutig, was ein Thread ist und was nicht.

Ich möchte nicht, das du den Quelltext offenlegts - ich möchte aber wenigstens wissen, mit was ich es bei einer PCU zu tun habe und nicht von total falschen Tatsachen ausgehen damit ich die Probleme auch an der richtigen Stelle suche und passend darauf reagieren kann. Wenn du mal die USER32.DLL diassemblest wirst du feststellen, das WM_TIMER (und WM_SYSTIMER) Notizie ganz anders behandelt werden, als der Rest der Messages. Andere Behandlung - andere Probleme. Benutzt du WM_TIMER?

Wenn keiner vermutet, das ein Problem evtl. an der PCU liegen potuto, weil er von ganz anderen Tatsachen ausgeht, wirst du auch keine Rückmeldungen in Bezug auf Fehler erhalten und das dieses Problem auch mit der PCU auftreten potuto bleibt weiterhin hypothetisch...

[quote:0b4d1bf92a]Ein Thread wird von den jeweiligen APIs als Thread angezeigt, hat eigene Zugriffsrechte und kann einen eigenen Token haben - ist also eindeutig, was ein Thread ist und was nicht.[/quote:0b4d1bf92a]
Hm nö - da bin ich nicht Deiner Meinung. Das ist vielleicht die Definition eines MS-Prozessthreads - aber diese Defi ist nicht allgemeingültig und weicht auch von der allgemeinen Threaddefinition ab. (Siehe Wiki) Und da ich eindeutig sage das ich keine Echten (also MS-Prozessthreads) erzeuge...

Ich nutze wm_timer und habe mir [...]

zunutze gemacht.