Multiprocessing proposed solution
Andre Garzia
soapdog at mac.com
Mon Sep 6 16:22:16 EDT 2004
Kevin,
Wow... that's hard... I solved some issues with multiprocessing in the
new instance of HTTPd, I think it works, the only problem is that if
some handler on user stack blocks, then I think the whole server will
block, but at least we can listen and answer to multiple sockets at the
same time. Theres a "ServerWorkz RC2 2.zip" inside
http://public.soapdog.org that can do this kind of stuff. The new
version libNetServices, is a hell better, it's a complete rewrite and
it's not available till I solve FTP upload and the inform engine...
I really would like to see this external you made we could make a rock
solid webserver using fork() like stuff and semaphores... for now,
libNetServices is a pure transcript solution, but I could fork the
codebase and open it so that other developers with more experience with
C code and externals could help.
Your effort is very welcome!!!!! You'll be the first to receive a
libNetServices T-Shirt when I am finished making them! (yes, I am
making them...)
Thanks!
andre
On Sep 6, 2004, at 4:58 PM, K wrote:
>
> Okay, Andre Garzia inspired me to investigate multi-processing using
> Runtime Revolution with his httpd stack. At first glance it seemed
> impossible nut through trial and error I have a semi-functional
> solution. I created a external wich is using a named sockets, pipes,
> mutexes, semaphores, events and even shared memory. Here is the break
> down....
>
>
> Process A (Parent)
> Process B (Child)
>
>
> Process 'A' using the sockets library in the GLIBExternal creates and
> listens on a selected port (in my case 80). Process 'A' accepts the
> call on a "named" socket. Then shell invokes process 'B' with the
> command line option --socket <named socket> (you can use any name you
> like) process B can now read and write to the named socket using the
> GLIBExternal socket interface. Process A and B can then cordinate
> their activities via named mutexes, semaphoes, events and shared
> memory blocks. Of course Process A must uniquely name each socket and
> provided that name to the GLIBExternal as well as the child process
> (demostrated below). I have not worked out the kinks of the shared
> memory on all platforms but I should be able to solve them in time.
> The implementation on Win32 is easier on Win32 and Linux since I am a
> experienced developer on those platforms.
>
> The low down is that Andre's httpd stack could operate simular to the
> Apache httpd using child processes to handle individual clients.
>
> Kevin
>
>
> /
> **_____________________________________________________________________
> _______________
>
> --Create a simple universal unique idenity<br>
> --<br>
> -- at param aSuffix just to customize the key a bit.
> -- at return empty success
> */
> function generateUUID aSuffix
>
>
> local tTime --Time portion of UUID
> local tRandom --Random portion of UUID
> local tAddress --Localhost address
> local tData --UUID Data
>
> put ticks() * 1000 into tTime
> put random( CONST_MAX_UUID_RANDOM ) * 10000000000000000 into tRandom
> put hostNameToAddress( hostName() ) into tAddress
>
> put tTime & tRandom & tAddress & aSuffix into tData
>
> put md5Digest( tData ) into tData
> put base64encode( tData ) into tData
>
> return tData
>
> end generateUUID
>
>
> -==-=-=-=-=-=-==-=-=-=-=-=-=-=-==-=-=-=-=-=-
> Disclaimer:
>
> Any resemblance between the above views and those of my
> employer, my terminal, or the view out my window are purely
> coincidental.
> Any resemblance between the above and my own views is
> non-deterministic.
>
> The question of the existence of views in the absence of anyone to
> hold
> them
> is left as an exercise for the reader. The question of the existence of
> the reader
> is left as an exercise for the second god coefficient.
> (A discussion of non-orthogonal, non-integral polytheism is beyond the
> scope of this article.)
>
>
>
> _______________________________________________
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
--
Andre Alves Garzia ð 2004
Soap Dog Studios - BRAZIL
http://studio.soapdog.org
More information about the use-livecode
mailing list