the general serve is not sufficient
in [ASM]
|
Prev: Delphi 2007 move routine flawed ?
Next: what timer?
From: io_x on 27 Jun 2010 03:26 "io_x" <a(a)b.c.invalid> ha scritto nel messaggio what about this? ; int FunzioneDelServer(i8** argm) ; ; Essa: ; 0) scrive nella finestra MD_ED_SERVER una "A" [server attivato] ; 1) crea un thread per stampa input dal socket alla finestra; ; tale subtrhead ; bloccaLaRisorsaSys(UsoSocket) ; estrae fd del soket che usa dopo ; liberalarisorsaSys(UsoSocket) ; usa fd con select per vedere se vi e' un evento read ; .a: se l'evento e' read ; bloccaLaRisorsaSys(UsoSocket) ; legge il socket ; liberalarisorsaSys(UsoSocket) ; invia tutto alla finestra ; altrimenti controlla che l'evento "eventoUscitaSottoThread" ; nel qual caso ; resetta eventoUscitaSottoThread ; esce ; goto .a ; 2) aspetta indefinitivamente per i messaggi: ; eventoUscitaFun [il secondo dell'array di eventi 4] ; bloccaLaRisorsaSys(UsoSocket) ; chiude il socket ; liberalarisorsaSys(UsoSocket) ; cosi' la select del sottotread deve ritornare ; setta l'evento "eventoUscitaSottoThread" ; resetta l'evento "eventoUscitaFun" ; eventoInviaDati [il terzo dell'array di eventi 12] ; legge la finestra di invio dati ; bloccaLaRisorsaSys(UsoSocket) ; scrive la finestra invio dati nel socket ; liberalarisorsaSys(UsoSocket) ; resetta l'evento "eventoInviaDati" ; eventoUscitaSottoThread [ho capito che si puo' fare 16] ; nel qual caso esce dal loop ; LiberaMemoriaRisorsaSys(UsoSocket) ; libera le risorse del subthread ; scrive nella finestra MD_ED_SERVER una "" [stringa vuota] ; esce dalla funzione if there is one subthread that close one socket then if one other thread has one select() that wait to +oo for read only for that same soket than if the socket is close, the select function return? WaitForMultipleObjects() function is good to for thread exit [pass the handle]?
From: io_x on 27 Jun 2010 03:30 "io_x" <a(a)b.c.invalid> ha scritto nel messaggio news:4c26fac9$0$18994$4fafbaef(a)reader5.news.tin.it... > > "io_x" <a(a)b.c.invalid> ha scritto nel messaggio > > what about this? > > ; int FunzioneDelServer(i8** argm) > ; > ; Essa: > ; 0) scrive nella finestra MD_ED_SERVER una "A" [server attivato] > ; 1) crea un thread per stampa input dal socket alla finestra; > ; tale subtrhead > ; bloccaLaRisorsaSys(UsoSocket) > ; estrae fd del soket che usa dopo > ; liberalarisorsaSys(UsoSocket) > ; usa fd con select per vedere se vi e' un evento read > ; .a: se l'evento e' read > ; bloccaLaRisorsaSys(UsoSocket) > ; legge il socket > ; liberalarisorsaSys(UsoSocket) > ; invia tutto alla finestra > ; altrimenti controlla che l'evento "eventoUscitaSottoThread" > ; nel qual caso > ; resetta eventoUscitaSottoThread > ; esce > ; goto .a > ; 2) aspetta indefinitivamente per i messaggi: > ; eventoUscitaFun [il secondo dell'array di eventi 4] > ; bloccaLaRisorsaSys(UsoSocket) > ; chiude il socket > ; liberalarisorsaSys(UsoSocket) > ; cosi' la select del sottotread deve ritornare > ; setta l'evento "eventoUscitaSottoThread" > ; resetta l'evento "eventoUscitaFun" ; goto 2 > ; eventoInviaDati [il terzo dell'array di eventi 12] > ; legge la finestra di invio dati > ; bloccaLaRisorsaSys(UsoSocket) > ; scrive la finestra invio dati nel socket > ; liberalarisorsaSys(UsoSocket) > ; resetta l'evento "eventoInviaDati" ; goto 2 > ; eventoUscitaSottoThread [ho capito che si puo' fare 16] > ; nel qual caso esce dal loop > ; LiberaMemoriaRisorsaSys(UsoSocket) > ; libera le risorse del subthread > ; scrive nella finestra MD_ED_SERVER una "" [stringa vuota] > ; esce dalla funzione > > if there is one subthread that close one socket > then if one other thread has one select() that wait to +oo for > read only for that same soket > than if the socket is close, the select function return? > > WaitForMultipleObjects() function > is good to for thread exit [pass the handle]? > > > >
From: Nathan Baker on 28 Jun 2010 16:09 "Frank Kotler" <fbkotler(a)myfairpoint.net> wrote in message news:i05ned$8r3$1(a)speranza.aioe.org... > > Well, I've got the "fake CreateThread(a)24" working... kinda. I'm not sure > what-all is not "right" with it, but it appears to be creating a thread > per connection. When the connection closes, the thread is leaving > "zombies" behind, so maybe I haven't got ExitThread@4 right... or maybe > it's "not my fault". First time I've created a zombie (that I know of). > From what I read, the cause is the caller not doing a "wait", so maybe > it's the "Windows code" that needs alteration... and I'll need to > implement a fake WaitForSingleProcess@?... or whatever you'd use. Does > Windows have "zombies"? If so, does your program create 'em? Not a problem > for this "toy" code - they disappear (seem to) when we exit the server. > Our "zombies" get blasted by the LazerPistol@ and PlasmaRiffle@ functions. :) Well, yeah, I believe one can say there are "zombies" in Windowsland by the fact that "kernel objects" can be left active. A kernel object, of course, is basically an internal structure the OS uses to manage a specific instance of a resource. The way I understand it, every time we call a function that returns a handle, that handle acts like a pointer to this kernel object. And it is possible to obtain multiple handles to the same object. The OS "keeps track" of how many handles it has provided for a specific object via incrementing the "usage count" for that object. So, for instance, if I create a disk file and obtain a handle to it, I should not later in the code assume that this is the only handle referencing that file. There could be some other code that obtains a handle to that file (via either accessing a member of an OS structure or by calling a function). So, if I close the file using my original handle, this does not (necessarily) garantee that the file will be closed and that its associated "kernel object" will be freed. That only happens when the "usage count" equals zero. Calling a "close???" style function only garantees that the 'usage count' for that particular kernel object gets decremented. Therefore, in order to exterminate all "zombies," one would need to track-down all posible handles to those objects and close them all. So, yes, a call to ExitThread@ probably only terminates the execution of code in that thread, but probably does not garantee that the thread's associated "kernel object" is freed. And that is why we can use functions like WaitForSingleObject@ and WaitForMultipleObject@ to test if a thread (or group) has finished executing. This would be the equivalent of a "Join" statement/function in other languages/threading implimentations. For this quick-n-dirty toy, I didn't see a need for a Join feature. But then, there are other technical problems with the code too. For instance, 'accept' blocks until a new connection is available. Would be better to use something like 'select' first to check if a new socket is available and then use 'accept' to connect to it. Similar issues exist with the 'recv' command -- we really should wait for the content to be available before attempting to obtain it. So, "the general server is not sufficient" -- that's right, a lot of specific thought and design is necessary to construct one that suffices. Nathan.
From: io_x on 30 Jun 2010 14:22 [alt.lang.asm,comp.os.ms-windows.programmer.win32] "io_x" <a(a)b.c.invalid> ha scritto nel messaggio news:4c2b0cd3$0$12128$4fafbaef(a)reader4.news.tin.it... > > "Frank Kotler" <fbkotler(a)myfairpoint.net> ha scritto nel messaggio > news:i05ned$8r3$1(a)speranza.aioe.org... >> Nathan wrote: >>> On Jun 25, 4:25 pm, Frank Kotler <fbkot...(a)myfairpoint.net> wrote: >>>> Nathan Baker wrote: >> it's "not my fault". First time I've created a zombie (that I know of). From >> what I read, the cause is the caller not doing a "wait", so maybe it's the >> "Windows code" that needs alteration... and I'll need to implement a fake >> WaitForSingleProcess@?... or whatever you'd use. Does Windows have "zombies"? yes i have one sub thread of the function that not close... it was generated from the OS api function ws2_32.gethostname(char* string, int size) in a OS Windows 7, is it a bug? there is someone of you know what is the function for OS windows 32 bit for know the IP address or name of the PC in which the program run? >> If so, does your program create 'em? Not a problem for this "toy" code - they >> disappear (seem to) when we exit the server. >> >> I guess this works well enough to post. I claimed it was the "same code" as >> for Windows. I lied. Linux just doesn't like backslashes in filenames, so I >> "flipped" 'em. I think Windows will tolerate forward slashes. If it's a >> problem, we can easily "%ifdef" it to one or the other. Aside from a couple >> cosmetic changes, I think that's the only alteration I did to your code. I'll >> repost it anyway:
From: io_x on 7 Jul 2010 05:26
"io_x" <a(a)b.c.invalid> ha scritto nel messaggio news:4c2b88ff$0$31370$4fafbaef(a)reader1.news.tin.it... > [alt.lang.asm,comp.os.ms-windows.programmer.win32] > yes i have one sub thread of the function that not close... > it was generated from the OS api function ws2_32.gethostname(char* string, > int > size) in a OS Windows 7, is it a bug? the problem is about close the program in this way main: .... ret with the return but like above there are no problem in windows xp the problem remain for windows 7 for not have subthread at the end i wuold use main: ExitProcess(0) ret the above remove the one more thread that sys create and remove the name of the program in the list of process seen with CTRL-ALT-CANC i think in all OS windows types but the memory of the program is correctly free from the sys? > there is someone of you know what is the function for OS windows 32 bit > for know the IP address or name of the PC in which the program run? > >>> If so, does your program create 'em? Not a problem for this "toy" code - >>> they >>> disappear (seem to) when we exit the server. >>> >>> I guess this works well enough to post. I claimed it was the "same code" as >>> for Windows. I lied. Linux just doesn't like backslashes in filenames, so I >>> "flipped" 'em. I think Windows will tolerate forward slashes. If it's a >>> problem, we can easily "%ifdef" it to one or the other. Aside from a couple >>> cosmetic changes, I think that's the only alteration I did to your code. >>> I'll >>> repost it anyway: > > > > > |