Prev: Delphi 2007 move routine flawed ?
Next: what timer?
From: Frank Kotler on 25 Jun 2010 16:25 Nathan Baker wrote: .... > invoke CreateThread, 0, 0, sockthread, eax, 0, tid Jeez, Nathan... :) For those who don't know (most people, I guess) Nathan and I are kind of "conspiring", with an eye to a "portable" version of the clax moderation software. Nathan has provided a few "tests", and I attempt to write "fake APIs" which will allow the same source code to assemble, link... maybe even run... on Linux. So far it's extremely rudimentary, but "going fairly well". But "CreateThread(a)24" (the "true" name) has got me stumped. If I eliminate that (replaced with "call sockthread"), the rest of it works fine... but only for one connection (which was the whole point). I'm trying to use sys_clone, which I have never used before. I find the documentation fairly confusing. Apparently "clone()" differs greatly from "sys_clone" (which is generally not the case). I may be able to "get it". If not, I may be able to do something with sys_fork... which I *have* gotten to work... once... It won't be right, but it might fill the immediate need. My goal is merely to provide the same names, same parameters, stdcall, and do "something roughly similar" anyway... I'm a little concerned with your use of "buf" in multiple threads. Is that going to work? Tough to really test it with multiple telnet sessions... Cross that bridge when we come it it, I guess. There are definitely limits to this little experiment. We may have come to it. Eye candy? I despair of even MessageBoxA! But for "socket stuff", I think this may work! We shall see... Best, Frank
From: H. Peter Anvin on 26 Jun 2010 00:29 On 06/25/2010 01:25 PM, Frank Kotler wrote: > > But "CreateThread(a)24" (the "true" name) has got me stumped. If I > eliminate that (replaced with "call sockthread"), the rest of it works > fine... but only for one connection (which was the whole point). I'm > trying to use sys_clone, which I have never used before. I find the > documentation fairly confusing. Apparently "clone()" differs greatly > from "sys_clone" (which is generally not the case). The reason the libc clone() wrapper is different is because sys_clone doesn't set up a stack in the cloned process, and therefore *has* to be invoked from assembly. libc creates a minimal-ish wrapper for that. If you want to use threading facilities in a way that is compatible with libc, however, you really want to use pthread_create() though. -hpa
From: Frank Kotler on 26 Jun 2010 02:03 H. Peter Anvin wrote: .... > The reason the libc clone() wrapper is different is because sys_clone > doesn't set up a stack in the cloned process, and therefore *has* to be > invoked from assembly. libc creates a minimal-ish wrapper for that. Okay... I've currently got "child_stack" set to zero. Re-reading the manual, I see that I *don't* want CLONE_VM set if I do that. That may be my problem. I'll try that, and/or allocating a stack to pass (I want top of the block of memory, right?)... I see that sys_clone went from 3 to 5 parameters between kernel 2.4 (what I'm running) and 2.6. That's going to throw me for a loop, I'll bet! > If you want to use threading facilities in a way that is compatible with > libc, however, you really want to use pthread_create() though. Okay... but only as a last resort... :) I realize that this is a completely insane thing to try to do! Thanks for the tip, Peter! Best, Frank
From: io_x on 26 Jun 2010 03:25 "io_x" <a(a)b.c.invalid> ha scritto nel messaggio news:4c24ccaf$0$19001$4fafbaef(a)reader5.news.tin.it... > the exercise i think is this: > > i have one function that > 1) has to see if one button is push > if it is push it has to send to socket one string > gets to one window > 2) has to see if another button is push > if it is push it has to exit > 3) has to see if socket receive one string > and if receive has to print it in another window > > how i can manage all that, with select? > With WaitForMultipleObject? > > if say the true i thought about this function > it is call from the CreateThread fucntions > and has all information > > one function that > .a: open one subthread > .1: that subthread use select for read-write select only to read > if the socket has data to read > use one semaphore for use the socket > read the socket > print it in a windows > check if events exitFunction, exitServer, are set > if some is set if it is set exitFunction reset it exit thread > else goto .1 > .b: wait for exitsubtread, sendData, exitFunction, exitServer, events > if exitsubtread event > exit of the function > if sendData event > gets from the windows the data > use one semaphore for use the socket > write the socket > goto .b > if exitFunction, exitServer, events > use one variable to know this operation is one time only > use one semaphore for use the socket > write the socket \0 here close the socket => so the select of the subtread has to return > goto .b >
From: Nathan on 26 Jun 2010 14:58
On Jun 25, 4:25 pm, Frank Kotler <fbkot...(a)myfairpoint.net> wrote: > Nathan Baker wrote: > > ... > > > invoke CreateThread, 0, 0, sockthread, eax, 0, tid > > Jeez, Nathan... :) > I had a hunch that you would give it a try. Instead of using threads, one can simply use an array to keep track of the sockets. Then poll each socket for activity... when a socket says it needs attention, care for its needs and then return to the polling loop. On the downside, it can cause the clients to experience blocking effects. > I'm a little concerned with your use of "buf" in multiple threads. Is > that going to work? Tough to really test it with multiple telnet > sessions... Cross that bridge when we come it it, I guess. > Works for this little proggy because it only deals with a single character at a time. Anything more complex will demand seperate resources per thread/socket. > There are definitely limits to this little experiment. We can keep discovering all of the "boundary lines" until we have collected a maximum set of "portable fake APIs" to put into the kit. Nathan. |