• Odpowiedz

@peceha, post #1

• Odpowiedz

@kiero, post #2

• Odpowiedz

@kiero, post #2

No i przyszla kolej na ... osobny proces

Na razie czytalem tylko ogolnie i nawet nie wiem jak mialbym komunikowac ten drugi proces z moim programem, a komenda CreateNewProc() to wciaz czarna magia.
Moglby ktos mi zaoszcedzc czasu i napisac co to NP_Seglist lub NP_Entry ?
Czy mam uzyc LoadSeg()? o co tu wogole chodzi....
co to jest "Scatterload a loadable file into memory"
Czy to wszystko bedzie mi potrzebne by wystartowac drugi proces z mojego programu?

• Odpowiedz

@peceha, post #4

Na razie czytalem tylko ogolnie i nawet nie wiem jak mialbym komunikowac ten drugi proces z moim programem, a komenda CreateNewProc() to wciaz czarna magia.

Procesy komunikują się przez porty. Po prostu tworzysz port za pomocą CreateMsgPort(), przekazujesz tworzonemu procesowi (jako parametr dla CreateNewProc()) a następnie wysyłasz (PutMsg()) oraz odbierasz (GetMsg()) wiadomości.

Moglby ktos mi zaoszcedzc czasu i napisac co to NP_Seglist lub NP_Entry ?
Czy mam uzyc LoadSeg()? o co tu wogole chodzi....
co to jest "Scatterload a loadable file into memory"
Czy to wszystko bedzie mi potrzebne by wystartowac drugi proces z mojego programu?

Ten nowy proces musi mieć uruchomiony jakiś program. LoadSeg() ładuje ten program z pliku wykonywalnego. Program wykonywalny to lista segmentów, w których każdy może mieć inny typ (kod, dane) oraz być umiejscowiony w różnych obszarach pamięci (CHIP, FAST).

Można też załadować program procesu z adresu pamięci. I tu przydaje się NP_Entry.

Ostatnia aktualizacja: 29.09.2019 15:18:22 przez Hexmage960

• Odpowiedz

@peceha, post #4

• Odpowiedz

@docent, post #6

• Odpowiedz

@peceha, post #4

struct Process *Proc_Procedura = NULL;
struct Task    *Task_MainTask;

void Procedura(void);

int main(void)
{
        T_MainTask = FindTask(NULL); 

        Proc_Procedura = CreateNewProcTags(NP_Entry, (ULONG)&Procedura,
                                   NP_Priority, 0,
                                   NP_Name, (ULONG)"Cos_tam",
                                   TAG_END);

// jaks dalsza czesc programu
.....

// przy zakonczeniu calego programu czekaj az drugi task skonczy

        Wait(SIGBREAKF_CTRL_C);
}

void Procedura(void)
{
...... // jakas procedura


// a teraz wyjscie przy zamykaniu programu

        Forbid();
        Signal(T_MainTask, SIGBREAKF_CTRL_C);
        Permit();
}

• Odpowiedz

@Phibrizzo, post #8

• Odpowiedz

@Phibrizzo, post #8

• Odpowiedz

@Hexmage960, post #5

• Odpowiedz

@docent, post #10

• Odpowiedz

@mschulz, post #12

• Odpowiedz

@Jacek Piszczek, post #13

• Odpowiedz

@mschulz, post #12

• Odpowiedz

@docent, post #15

To od pecha nie zalezy :)
Jesli uzyjesz Permit, to wywola on scheduler - w efekcie sa 4 mozliwosci zachowania sie systemu:
1. Jesli biezacy task (sub task) jest w stanie wyjatku, wywoluje jego obsluge wyjatku z TaskExceptCode
2. Jesli nastepny gotowy task ma wiekszy priorytet, jest on przelaczany i wykonywany
3. Jesli nastepny gotowy task ma mniejszy/rowny priorytet i quantum subtasku jeszcze nie minelo -> subtask jest dalej wykonywany
4. Jesli nastepny gotowy task ma mniejszy/rowny priorytet i quantum subtasku juz minelo -> nastepny gotowy task jest przelaczany i wykonywany

Klopoty moga sie pojawic tylko w przypadku 2 i 4, gdy glowny task ma priorytet wyzszy/rowny priorytetowi sub tasku i moze zakonczyc prace przed sub taskiem, co moze zakonczyc sie crashem. Jesli glowny task ma ten sam priorytet co sub task to punkt 2 nie ma znaczenia i pozostaje tylko punkt 4
Wystarczy wiec by sub task mial priorytet wiekszy od glownego by zastosowanie Permit bylo calkowicie bezpieczne.

Dokladnie. Ale skoro juz o porzadnym programowaniu mowimy a nie o brzydkich hakach, na dokladke nie kontrolujemy quantum, to nie zakladajmy z gory ze ustawienie wyzszego priorytetu zalatwia sprawe na zawsze. Wystarczy ze Pecha zmieni kiedys priorytet subtasku z jakiegos powodu zapominajac o tym, ze uzyl "calkowicie" bezpiecznego Permit() albo zainstaluje sobie jakis super-hiper nowy scheduler ktory nie bedzie sie trzymal wyzej wymienionych zasad. Pozwol ze zacytuje jednoczesnie lekko modyfikujac cytat (modyfikacja pogrubiona ):

to takie hakerskie rozwiazanie, ktore w tym przypadku pewnie zadziala, ale tylko jesli subtask ma wyzszy priorytet niz glowny task. Latwo tu o jakies przeoczenie i trudny do zlokalizowania blad

A z mojej strony, widzialem juz i poprawialem kod ktorego autor mial podobne zalozenia tyle ze odnosnie momentu tworzenia subtasku. Potem zmienil priorytety i trzeba bylo grzebac w kodzie i dociekac dlaczego subtask widzi pewne zmiennie niezainicjalizowane, mimo ze przeciez sa w kodzie ustawione ;)

Ostatnia aktualizacja: 01.10.2019 14:01:24 przez mschulz

Ostatnia aktualizacja: 01.10.2019 14:03:12 przez mschulz

• Odpowiedz

@mschulz, post #16

• Odpowiedz

@mschulz, post #16

• Odpowiedz

@peceha, post #1

Mialem problem w wystartowaniu supprocesu z kodu glownego w blitzu (ciagle zwisy) az na EAB mi powiedziano ze nie da rady.

Takze droga jaka przyjalem to 2 osobne programy.
Startuje ten odpowiedzialny za MHI, on tworzy port ogolny a nastepnie poprzez Execute() staruje program odpowiedzialny za cale GUI. Ten z kolei wysyla wiadomosci do ogolnego i odbiera odpowiedzi.
Gdy zamkne okno, wysylana jest wiadomosc z ustawionym polem o zakonczeniu programu i ten odpowiedzialny za MHI zamyka port ogolny odpowiada na te wiadomosc i znika. Jak program GUI odbierze odpowiedz i tam bedzie ustawione pole o zakonczeniu to tez posprzata i sie zamnkie.

Zakladam ze musze otworzyc tez drugi port ogolny z programu odpowiedzialnego za GUI by ten z MHI mogl wysylac informacje o stanie playback-u.

Co by nie bylo, prototyp dziala wiec jest gitara

Mam jedno pytanie, czy na odpowiedzi do wiadomosci tez musze odpowiadac?
Chyba nie?

• Odpowiedz

@peceha, post #19

• Odpowiedz

@Krashan, post #20

Zauwazylem, ze Blitz wlasnie staje sie kula u nogi...
Przyklad sprzed dwoch dni:
by pisac "systemowo" potrzeba do blitza specjalnej biblioteki
- rozprowadzana oryginalnie z BB2 ma problem z komenda Wait() gdy uzywam maski a do tego brakuje jej structury AppWindow wiec odpada "drag and drop"
- kolejna wersja (chronologicznie) i nie oficjalna to z aminetu amigalibsii. Fajna sprawa, ze naprawili Wait() i dodali AppWindow ale zapomnieli o DataType oraz BitMapHeader (czyli szlag trafil obsluge datatypes)
- 3cia i ostatnia to "oficjalna" z "duzej" dystrybucji blitza. Dodali brakujace rzeczy ale spieprzyli \fr_NumArgs gdy ustawi sie MULTISELECT (zwracane sa totalne bzdury) - czyli wybieranie kilku plikow na raz do kosza.
-jest jeszcze 4ta opcja "all.res" (dla amiblitz) ale ta wiesza mi amige
To tylko przyklady jakie sam napotkalem piszac proste GUI.

Dodatkowo mam sporo pomyslow ktorych zrealizowac nie moge chocbym nie wiem jak chcial , bo nie da rady spod Blitza.

Dzeki za proste wyjasnienie wiadomosci

• Odpowiedz