Új hozzászólás Aktív témák

• #2508 #39560925 törölt tag kingabo #2507

  Új Válasz 2014-07-20 22:33:51 #2508

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz kingabo #2507 üzenetére

  Tudom mit csinál az a try-catch blokk, az előzményt is olvasd el. Csak debugolas céljából volt ott. Végülis fölöslegesen, mert már emvy segítségével megoldódott a probléma.

  Tehát az előzmény:
  SO-n azt írták, hogy egy kezeletlen exception miatt meghívódik a terminate() ami meghívja az alkalmazás abort()-ját és ezért áll le.
  Próbáltam, hogy try-catch blokkba elkapok mindent a függvényhívás körül, de ugyan úgy abortálódott a futás. Egyébként msdn-en semmit nem írnak arról, hogy ezek a függvények exceptiont dobnának.

• #2506 #39560925 törölt tag emvy #2505

  Új Válasz 2014-07-20 21:19:49 #2506

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz emvy #2505 üzenetére

  Ja ott már mindent bekapcsoltam, SO-n olvastam róla, de nem okozott változást.

• #2504 #39560925 törölt tag emvy #2503

  Új Válasz 2014-07-20 21:14:59 #2504

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz emvy #2503 üzenetére

  Igen, a bufferek szeparáltak.

  Egyelőre csak a just my code-ot tudtam kikapcsolni, a többit még keresem.

  Okés, felrakom a skype-ot, az itthoni asztali gépen eddig nem használtam.

• #2502 #39560925 törölt tag emvy #2501

  Új Válasz 2014-07-20 21:04:33 #2502

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz emvy #2501 üzenetére

  Először is odaadom a Socket és az UDP_Socket forrását. A thread indítása elég összetett és inkább nem adnám oda. A threadként elindított függvény egy objektum tagfüggvénye, és ezt az objektumot először inicializálom az első beérkező csomag függvényében.

  Így deklarálom az objektumot:
  auto forwarder = std::make_shared<RTP_proxy>();

  Ha a csomagban megfelelő content van és még nem létezik forwarder a forráscímhez tartozóan, akkor csinálok egy új forwardert:
  forwarder = std::make_shared<RTP_proxy>(proxy_IP, rtp_addr, call_ID);

  Hozzáadom a forwardereket tároló map-hez:
  RTP_forwarder_list[rtp_addr] = forwarder;

  És elindítom az új szálat:
  std::thread(&RTP_proxy::run, RTP_forwarder_list[rtp_addr].get());

• #2500 #39560925 törölt tag #39560925 #2499

  Új Válasz 2014-07-20 20:04:53 #2500

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz #39560925 #2499 üzenetére

  Tehát az UDP_Socket operator<< függvénye lentebb olvasható (mint mondtam is, mindig működik). A sender_address és a sender_port egy std::string és uint16_t típusú, inicializált változók.

  Itt megtörtént a standard outputra kiírás:
  

  De közben felvillan a "debug error!" hibaüzenet, amiből utána ennyi látszik:
  

  Jó, mi?

• #2499 #39560925 törölt tag emvy #2498

  Új Válasz 2014-07-20 19:43:32 #2499

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz emvy #2498 üzenetére

  az opertor<< nem csinál semmit csak kiír. Az is mindig jól működik, kivéve ebben a szálban. Nem használ közös adatot, két külön objektumról van szó amik a saját tagváltozóit írják ki.

  std::ostream& operator<<(std::ostream& os, const Socket& sock)
  {
  os << sock.IP_address << ":" << sock.port;
  return os;
  }

  A két szál közös adatai meg mutex-ekkel védett stl tárolók, de odáig most nem jut el a program, hogy használja is őket a második szál.

• #2497 #39560925 törölt tag emvy #2496

  Új Válasz 2014-07-20 19:16:41 #2497

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz emvy #2496 üzenetére

  Igen. Most kiviszem a kutyákat aztán megmutatom, hogy a hibás szálon egy sima std::cout-ra kiírással is tudok debug errort csinálni.

• #2495 #39560925 törölt tag #39560925 #2494

  Új Válasz 2014-07-20 19:07:25 #2495

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz #39560925 #2494 üzenetére

  Kicsit elrontottam a debugolási lépések leírását, nem azok a képek vannak, amikre emlékeztem.

  Szóval a második képhez tartozó helyes szöveg ez lenne: várakozik is csomagra timeout nélkül, ahogy annak lennie kell.

  Az első képhez meg csak annyi a komment, hogy meghívódik a recvfrom()

• #2494 #39560925 törölt tag emvy #2493

  Új Válasz 2014-07-20 19:00:17 #2494

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz emvy #2493 üzenetére

  Részleteket tudok mutatni, és elmondom mit csináltam.

  Elöljáróban annyit, hogy csináltam egy wrapper osztályt a winapi köré, hogy OO módon tudjam kezelni socketeket, és amúgy tök jól működik.

  Itt az 1. számú szálon meghívódik a rcvfrom() és várakozik is csomagra timeout nélkül, ahogy annak lennie kell:
  

  Miután küldök neki egy csomagot, azt szépen feldolgozza a szál:
  

  És visszatér a recvfrom:
  

  Ezek után elindítja a 2. számú szálat, ami egy másik socketre hívja meg a recvfrom()-ot:
  

  Megnyomom az F11-et (step into) és voilà:
  

  Látom szerkesztettél és call stack kell, intézek egyet.
  Itt a call stack, nyilván csak az abortot előidéző utasításig tudom megnézni:
  

• #2492 #39560925 törölt tag #39560925 #2491

  Új Válasz 2014-07-20 18:28:27 #2492

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz #39560925 #2491 üzenetére

  Senkinek nincs ötlete?

• #2491 #39560925 törölt tag #39560925 #2490

  Új Válasz 2014-07-19 10:56:19 #2491

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz #39560925 #2490 üzenetére

  Amugy irtam kis kiegeszito programokat amikkel kiprobaltam, hogy mukodik-e amit csinalok, es mukodik. Meg ezen a programon belul is mukodik, csak azon a bizonyos szalom nem.

• #2490 #39560925 törölt tag

  Új Válasz 2014-07-19 10:44:23 #2490

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  [link]

  winapit socketet használó programot írok. Amikor egy ezzel kapcsolatot api hívást csinálok az egyik szálból, pl select(), vagy recvfrom(), akkor elszáll a program a fenti hibaüzenettel. Túrtam elég sokat a netet, de nem találtam róla semmi használhatót.
  SO-n azt írták, hogy egy kezeletlen exception miatt meghívódik a terminate() ami meghívja az alkalmazás abort()-ját és ezért áll le.
  Próbáltam, hogy try-catch blokkba elkapok mindent a függvényhívás körül, de ugyan úgy abortálódott a futás. Egyébként msdn-en semmit nem írnak arról, hogy ezek a függvények exceptiont dobnának.
  Én arra gyanakszom, hogy a többszálúság miatt lehet, de minden socketet csak egy, a saját szálából használok. Egyébként is úgy debugoltam, hogy a másik szál aludt, mikor erre a függvényhívásra lépett az utasításszámláló.

  A másik furcsa jelenség a következő: overloadoltam az operator<<-t az egyik saját osztályomnak. Tökéletesen működik mindig, kivéve abban a szálban, ami a fenti hibát produkálja. Egész pontosan mikor megtörténik az outputra kiírás, akkor is dob egy ilyen hibaüzenetet, de ekkor még tovább tudom futtatni a programot. WTF?

  UI: bocs, hogy nem print screeneltem, a szituációban egyszerűbb volt fotózni.

• #2487 #39560925 törölt tag WonderCSabo #2484

  Új Válasz 2014-07-01 18:25:45 #2487

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz WonderCSabo #2484 üzenetére

  A legtöbb példában amit láttam nem egy osztály tagfuggvenyet adták át, hanem egy globális függvényt, ezért először nem értettem, hogy miért kell 2 paraméter a thread konstruktorának, aztán végül leesett.

  emvy: valóban tökmindegy, csak annyi, hogy a mainben meg be kell várni azt a szálat.

  Amúgy deklaráltam egy threadeket tároló listát és abba pusholtam bele a futás közben létrehozott threadeket, aztán a létrehozó szál végén vegigiteraltam a listán és mindre meghívtam a joint, így rendben működik.

• #2482 #39560925 törölt tag #39560925 #2481

  Új Válasz 2014-07-01 17:03:40 #2482

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz #39560925 #2481 üzenetére

  Hazafelé menet leírom hogy mit csináltam, hátha segít majd egyszer valakinek, bár nem egy nagy mágia.

• #2481 #39560925 törölt tag emvy #2480

  Új Válasz 2014-07-01 15:57:09 #2481

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz emvy #2480 üzenetére

  Még kicsit rágódni fogok rajta, mert futási időben dől el hogy hány szál lesz, és ugyebár be kell várni a szálakat annak a szálnak ami indítja őket, és ez az esetemben nem is a főszál, hanem egy másik szál

  Elég fura a szintakszis java után.

• #2479 #39560925 törölt tag

  Új Válasz 2014-07-01 15:08:11 #2479

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  Van egy osztály, amiben van egy függvény aminek nincs paramétere és nincs visszatérési értéke. Ezt a függvényt szeretném meghívni egy másik osztályból külön szálként std:threadet használva. Ennek mi a helyes módja?

Új hozzászólás Aktív témák