amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > filerequester task [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 -3- [ - Beitrag schreiben - ]

30.12.2011, 20:20 Uhr

AGSzabo
Posts: 1663
Nutzer 		@thomas:

Ich weiß jetzt nicht worauf du dich da bei mir beziehst. Mit dem SIGBREAKF_CTRL_F funktioniert es ja auch ohne Forbid. Es friert blos auch ohne das forbid ein. Meinst du es würde nimmer einfrieren wenn ich Ports und Messages verwende? Ist das für diesen einen Pointer nicht zu viel des Guten?

ps: neuere Studien ergeben, dass das Einfrieren garnicht bei CreateNewPRoc(), sondern in Examine() passiert sein könnte. Muss ich meinem Prozess für CreateNewProc() noch etwas mitgeben, das ich verpasst habe?

code:
.proctags	dc.l	NP_Entry,scandir_process
		dc.l	NP_Name,.procname
		dc.l	NP_StackSize,8000
		dc.l	NP_ExitCode,.process_exit
		dc.l	TAG_END

--
Author of Open eXternal User Interfaces - Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 30.12.2011 um 20:34 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
01.01.2012, 18:10 Uhr

AGSzabo
Posts: 1663
Nutzer 		Hier mal so zwischendurch der Stand der Dinge in Sachen Filerequester:

Bild: http://images.quicktunnels.net/oxfilereq.png
--
Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

[ - Antworten - Zitieren - Direktlink - ]
03.01.2012, 11:36 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
@thomas:
Ich weiß jetzt nicht worauf du dich da bei mir beziehst.
Wenn es eine Möglichkeit gibt, Forbid() zu vermeiden, sollte man diese auch nutzen.

Die Lösung lautet:

  • Parent startet neuen Process
  • Parent schickt Message mit Zeiger auf die gemeinsamen Daten an pr_MessagePort des neuen Prozesses

  • Child ruft gleich nach Start WaitPort() auf seinem eigenen pr_MessagePort auf

    Das sollte Dir übrigens bekannt vorkommen. Genau so teilt die Workbench jedem Programm mit, welche Icons beim Start geöffnet waren.

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]

    		•
    03.01.2012, 11:40 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von AGSzabo:
    während der scan task items anhängt und das layout neu berechnet, kann er nicht das dir einlesen.
    und dann wunderst Du Dich, dass es langsam ist?

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]
    03.01.2012, 12:00 Uhr

    AGSzabo
    Posts: 1663
    Nutzer     		@Holger:

    > und dann wunderst Du Dich, dass es langsam ist?

    ist es nimmer. der flaschenhals war das sortieren, das jetzt durch alfabetisches adden ersetzt wurde.

    > Das sollte Dir übrigens bekannt vorkommen. Genau so teilt die Workbench jedem Programm mit, welche Icons beim Start geöffnet waren.

    Ja, daran habe ich auch oft gedacht. Naja, jetzt funktioniert es anscheinend mit SIGF_BREAK_CTRL_F oder so, wie im Beispielsource.
    --
    Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

    [ - Antworten - Zitieren - Direktlink - ]
    03.01.2012, 12:10 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von AGSzabo:
    ist es nimmer. der flaschenhals war das sortieren, …
    Es ist jetzt kein Flaschenhals, solange der Datenträger vergleichsweise langsam ist. Bzw. fehlt Dir einfach nur der Vergleichswert dafür, wie schnell es sein könnte. Jedenfalls ist Dein Task mit Layoutberechnung beschäftigt, wenn eigentlich schon neune Daten gelesen werden könnten.

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]
    03.01.2012, 12:16 Uhr

    AGSzabo
    Posts: 1663
    Nutzer     		@Holger:

    > Jedenfalls ist Dein Task mit Layoutberechnung beschäftigt, wenn eigentlich schon neune Daten gelesen werden könnten.

    Ist es denn von Bedeutung welcher Task das Layout macht? Ich meine, wenn es der main task machen würde, könnte wäherenddessen der read task auch nicht weiter einlesen?
    --
    Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

    [ - Antworten - Zitieren - Direktlink - ]
    03.01.2012, 12:30 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von AGSzabo:
    Ist es denn von Bedeutung welcher Task das Layout macht? Ich meine, wenn es der main task machen würde, könnte wäherenddessen der read task auch nicht weiter einlesen?
    Die Datenübertragung erfolgt im Idealfall auf unterster Ebene via DMA. Aber nur, wenn man dam System eine Chance dazu gibt. Dazu muss das Programm dem System auch mitgeteilt haben, dass es etwas tun soll. D.h. direkt nachdem der Lesetask einen Eintrag erhalten hat (dann ist er auch aktiv), fordert er den nächsten an. Danach berechnet der GUI-Task das Layout, während das Laufwerk Daten zum Controller schaufelt.

    Wenn man die nächste Leseanfrage erst stellt, nachdem man das Layout berechnet hat, muss das Laufwerk Däumchen drehen.

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]
    03.01.2012, 12:37 Uhr

    AGSzabo
    Posts: 1663
    Nutzer     		@Holger:

    Zwei Zeilen geändert und schwupp erledigt der gui task das layout selber. Hat sich aber nix geändert. Liegt vielleicht daran, dass es der uae ist? Übrigens geht mein Einlesen im Emulator sehr viel viel schneller als das selbe directory direkt unter linux.
    --
    Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

    [ - Antworten - Zitieren - Direktlink - ]
    03.01.2012, 19:31 Uhr

    Holger
    Posts: 8116
    Nutzer     		@AGSzabo:
    Es gibt eine Menge Faktoren, die da eine Rolle spielen. In Deinen Setup werden in den meisten Fällen Daten aus einem Cache unter Verwendung der CPU kopiert, d.h. es geht ziemlich schnell und kann gleichzeitig nicht mehr durch asynchrone Abarbeitung beschleunigt werden.

    Native Linux-Programme sind da direkter, was nicht unbedingt immer vorteilhaft sein muss. Vor allem bot die Architektur bis vor kurzem keinerlei Anreize, anwendungsseitig asynchrone I/O zu verwenden.

    Darauf sollte man aber seine Amiga-Software nicht ausrichten.

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]

    1 2 -3- [ - Beitrag schreiben - ]


    amiga-news.de Forum > Programmierung > filerequester task [ - Suche - Neue Beiträge - Registrieren - Login - ]


    .
    Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
    Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
    .