J2ME + Bluetooth server + nevolja sa thred-om

[anqe1ki11er]

E ovako: pisem neku aplikaciju za mobilne telefone, aplikacija u sebi sadrzi bluetooth server koji treba da ceka dolazece konekcije od drugih uredjaja.
E sad, taj server, to jest jedna linija koda u njemu >>connection1=service1.acceptAndOpen();<< blokira trenutni thread.
Sto je normalno, to jest tako i treba da radi. Da bih omogucio da mi ta linija koda ne glavi celu aplikaciju ja sam deo koda koji pretstavlja server stavio u novi thread.
E sad SHOCK: umesto da ostatak aplikacije normalno radi, on to ne cini, to jest opet je blokiran od strane servera koji se nalazi u zasebnom thread-u.
Moje pitanje je: je li ovo normalno (nemoguce da je); jel' imao neko slicno iskustvo; i uopste koji je vrag glupom serveru, zasto glavi svoj thread i thread u kome se nalazi ostatak aplikacije (GUI...);

[seymourc64]

Obicno se pri pisanju servera u glavnom threadu stavi beskonacna petlja koja osluskuje klijente, a daemon niti(thread) pravis ako zelis da se radi jos nesto u pozadini+svaki put kreiras po jednu daemon nit kada se nakaci klijent.

E sada sto se tice tvog problema. Da li si siguran da se glavna nit ne prekida posle poziva nove niti koja je kreirana kao non-damon (program se zavrsava kada se zavrse sve njegove non-dameon niti, tako da nema veze sto ti se zavrsi main)? Mozda koristis neki deljeni resus u obe niti, pa si pogresio negde kod lock/unlock-a? Ako nije to, ne bih znao u cemu je problem. Inace, nisam radio ista za mobilne telefone, tako da govorim uopsteno...

[anqe1ki11er]

seymourc64 kaže:

Obicno se pri pisanju servera u glavnom threadu stavi beskonacna petlja koja osluskuje klijente, a daemon niti(thread) pravis ako zelis da se radi jos nesto u pozadini+svaki put kreiras po jednu daemon nit kada se nakaci klijent.

E sada sto se tice tvog problema. Da li si siguran da se glavna nit ne prekida posle poziva nove niti koja je kreirana kao non-damon (program se zavrsava kada se zavrse sve njegove non-dameon niti, tako da nema veze sto ti se zavrsi main)? Mozda koristis neki deljeni resus u obe niti, pa si pogresio negde kod lock/unlock-a? Ako nije to, ne bih znao u cemu je problem. Inace, nisam radio ista za mobilne telefone, tako da govorim uopsteno...

Aplikacija koju pisem nije server, serverom se naziva deo aplikacije koji osluskuje za dolaznim konekcijama u bluetooth terminologiji (bar sam to pokupio u literaturi), i nije u pravom smislu server (kao WEB, FTP...) vec isto sto i socket u networking terminologiji (Nadam se da si razumeo sta hocu da kazem). Ovaj "server" je samo mali deo aplikacije, ali pravi velike probleme (vec 2,5 dana se lomim oko njega). Gore navedena metoda je zamena za beskonacnu petlju, ona je ta koja neprestano ceka dolazne konekcije, i naravno posto beskonacno dugo radi blokira thraead u kome se nalazi, sto je noramalno, ali ono sto nije normalno je da doticna metoda blokira i thread u kome se nalazi GUI. Sto mi potpuno sasvim nije jasno. Inace u J2ME nema main metode (bar se ne zove tako). E sad, s obzirom da si uopsteno pisao vecina posta mi nije od pomoci, ali mislim da si u pravu za lock/unlock. Posto "server" koristi neke resurse iz GUI thread-a. Hvala ti

[anqe1ki11er]

JA SAM IDIOT. ALI JA SAM DEFINITIVNO IDIOT.
Pocinjem da mislim da sam bolji da cuvam ovce, nego da pisem Java code.
Posle 3 dana lomljenja mozga sam uocio gde je greska. A greska je u tome sto sam pri pozivanju "servera", koji je u drugom Thread-u od onog u kome je GUI, kucao:
Server ser = new Server();
Thread prvi = new Thread(ser);
prvi.run();
Umesto:
Server ser = new Server();
Thread prvi = new Thread(ser);
prvi.start();
Pa je JVM pokrenula server kao metodu druge klase, a ne u novom thread-u.