OpenEuphoria

2. Re: Threads vs Processes

• Posted by Mario Steele <eumario at trilake.net> May 02, 2005
• 507 views

Bruce Douglas wrote:
> 
> Hello, I am new at Euphoria and am really happy with it. I have 2
> projects in C++ which were stalled which I have ported to Euphoria
> and have made a lot of progress now. I am using wxEuphoria
> which is important for me because I work in Linux but deploy these
> programs on Windows computers.  So, thank-you, Rob and Matt!
> 
> I have been following your debate on threads vs. processes with
> great interest.  I hope this is not a dumb question. 
> 
> My question is how you implement processes? For example, I'm working
> on an email checker / deleter and would like to be able to connect
> simultaneously to several accounts. Also, I have times when the connection
> freezes but doesn't disconnect and then my poor program gets trapped in the
> socket call and never returns. I have a timer() call set up but the 
> program is
> not available to check the timer.
> 
> It would be nice if I could just call a procedure but not wait for it to 
> finish.
> When it was good and ready, it could generate an event or set a variable or
> whatever. If it doesn't return in a certain time, I can have the program 
> handle
> this more gracefully.
> 
> I would like to avoid using the Windows API calls since I would like my
> programs to still work in Linux.
> 
> Is there a way to implement this without threads?

If I am not mistaken, your creating your wxSocketClient, with the
wxSOCKET_WAITALL flag implaced.  I would suggest that you use the 
wxSOCKET_NOWAIT flag.  This will allow you to receive Asynchronous data,
without blocking the GUI.  This ofcourse means, that you must detect, and
buffer data, so that way you don't get any corruption in streamed data.

It is often suggestable to use builtin features of the library, before
breaking down, and using other methods in which to get your intention across
the program.

Something like this would be satisfactory:

sequence buff

procedure parseInfo()
     -- do your error detection here
     -- If there is more data to be retrived,
     -- then wait for it to be retrived,
     -- otherwise, if you have all the data
     -- do your parsing of it, saving, or whatever
     -- and pass it along to what ever needs it.
end procedure

procedure on_socket_email(atom this, atom event_type, atom id, atom event)
     seqence dat
     event_type = get_socket_event(event)
     if event = wxSOCKET_INPUT then
          dat = socket_read( socket_from_event(event) )
          if not equal({},dat) then
              buff &= dat
          end if
          if not equal({},buff) then
              parseInfo()
          end if
     end if
end procedure
set_event_handler(your_form, client_id, wxEVT_SOCKET,
routine_id("main_socket_event"))

This should allow you to parse all the information, without having to rely
on using sub-proccesses in order to stop the Blocking calls when you do
a socket_read() event.

Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...

4. Re: Threads vs Processes

• Posted by Bruce Douglas <bruce_list at tutopia.com.br> May 03, 2005
• 533 views

Mario,

At this point, I'm using Simple Sockets Lib by jbrown as this was 
quicker for me
to get going. I think switching to the wxEuphoria socket functions and 
setting up
socket response functions will help handle connection freezes (and maybe 
give
the GUI time to to redraw the window, etc). I'll be trying this in the 
next couple of
day, work permitting.  I'm not sure that this would allow me to have 
simultaneous
downloads, though.

Thanks for your help. In the next few days, I will be trying the 
wxEuphoria socket
functions again and certainly use your advice.

Thank-you,
Bruce Douglas

Mario Steele wrote:
> If I am not mistaken, your creating your wxSocketClient, with the
> wxSOCKET_WAITALL flag implaced.  I would suggest that you use the 
> wxSOCKET_NOWAIT flag.  This will allow you to receive Asynchronous data,
> without blocking the GUI.  This ofcourse means, that you must detect, and
> buffer data, so that way you don't get any corruption in streamed data.
> 
> It is often suggestable to use builtin features of the library, before
> breaking down, and using other methods in which to get your intention across
> the program.
> 
> Something like this would be satisfactory:
> 
> }}}
<eucode>
> sequence buff
> 
> procedure parseInfo()
>      -- do your error detection here
>      -- If there is more data to be retrived,
>      -- then wait for it to be retrived,
>      -- otherwise, if you have all the data
>      -- do your parsing of it, saving, or whatever
>      -- and pass it along to what ever needs it.
> end procedure
> 
> procedure on_socket_email(atom this, atom event_type, atom id, atom event)
>      seqence dat
>      event_type = get_socket_event(event)
>      if event = wxSOCKET_INPUT then
>           dat = socket_read( socket_from_event(event) )
>           if not equal({},dat) then
>               buff &= dat
>           end if
>           if not equal({},buff) then
>               parseInfo()
>           end if
>      end if
> end procedure
> set_event_handler(your_form, client_id, wxEVT_SOCKET,
> routine_id("main_socket_event"))
> </eucode>
{{{

> 
> This should allow you to parse all the information, without having to rely
> on using sub-proccesses in order to stop the Blocking calls when you do
> a socket_read() event.
> 
> Mario Steele
> http://enchantedblade.trilake.net
> Attaining World Dominiation, one byte at a time...

6. Re: Threads vs Processes

• Posted by Mario Steele <eumario at trilake.net> May 03, 2005
• 512 views
• Last edited May 04, 2005

Bruce Douglas wrote:
> 
> Mario,
> 
> At this point, I'm using Simple Sockets Lib by jbrown as this was 
> quicker for me
> to get going. I think switching to the wxEuphoria socket functions and 
> setting up
> socket response functions will help handle connection freezes (and maybe 
> give
> the GUI time to to redraw the window, etc). I'll be trying this in the 
> next couple of
> day, work permitting.  I'm not sure that this would allow me to have 
> simultaneous
> downloads, though.

Ahh, okay, I see what your talking about now.  Yeah, jbrown's socket library
can be confusing at time, but you can still do Asynchronous connections with
it.  But the problem with it is, you'll be forced to change the code, when
you want it to work on both Linux, and Windows.  It's easier to switch now
then to work on jbrown's library, get everything working, then have all this
work that becomes basically useless, when you need to switch to a Windows
interface.

Now, the part about "not sure that it would allow you to have simultaneous
downloads", that part you are wrong on.  One major thing you need to realize,
that when creating a Socket, it's just like creating a window.  2 Windows can
be running at the same time, with no problems, and the Euphoria code will 
handle the code for each window with no problem.  Sockets are the same way,
especially Event Based Sockets (As I like to call them.)

See, when I was back on windows, I used Jason Mirwald's TCP.ew library, which
is a most excellent library out there.  However, it lacks the portability
issue, so I won't go to much into it, except to show you a small
demonstration of how you can get two downloads at the same time, with no
interruption.

include win32lib.ew
include tcp.ew

constant download = create(Window,"Downloader",0,Default,Default,300,200,0)

sequence socks, buffs socks = {} buffs = {}

function onWM_SOCKET(atom lt, atom hWnd, atom iMsg, atom wParam, atom lParam) atom msg, error msg = lo_word(lParam) error = hi_word(lParam) if find(wParam,socks) then if msg = FD_READ and error = 0 then buffs &=

Mario Steele http://enchantedblade.trilake.net Attaining World Dominiation, one byte at a time... }}}

8. Re: Threads vs Processes

• Posted by Mario Steele <eumario at trilake.net> May 04, 2005
• 574 views

Bruce Douglas wrote:
> 
> Mario,
> 
> At this point, I'm using Simple Sockets Lib by jbrown as this was 
> quicker for me
> to get going. I think switching to the wxEuphoria socket functions and 
> setting up
> socket response functions will help handle connection freezes (and maybe 
> give
> the GUI time to to redraw the window, etc). I'll be trying this in the 
> next couple of
> day, work permitting.  I'm not sure that this would allow me to have 
> simultaneous
> downloads, though.

Ahh, okay, I see what your talking about now.  Yeah, jbrown's socket library
can be confusing at time, but you can still do Asynchronous connections with
it.  But the problem with it is, you'll be forced to change the code, when
you want it to work on both Linux, and Windows.  It's easier to switch now
then to work on jbrown's library, get everything working, then have all this
work that becomes basically useless, when you need to switch to a Windows
interface.

Now, the part about "not sure that it would allow you to have simultaneous
downloads", that part you are wrong on.  One major thing you need to realize,
that when creating a Socket, it's just like creating a window.  2 Windows can
be running at the same time, with no problems, and the Euphoria code will 
handle the code for each window with no problem.  Sockets are the same way,
especially Event Based Sockets (As I like to call them.)

See, when I was back on windows, I used Jason Mirwald's TCP.ew library, which
is a most excellent library out there.  However, it lacks the portability
issue, so I won't go to much into it, except to show you a small
demonstration of how you can get two downloads at the same time, with no
interruption.

include win32lib.ew
include tcp.ew

constant download = create(Window,"Downloader",0,Default,Default,300,200,0)

sequence socks, buffs
socks = {}
buffs = {}

function onWM_SOCKET(atom lt, atom hWnd, atom iMsg, atom wParam, atom lParam)
     atom msg, error, dat, size
     msg = lo_word(lParam)
     error = hi_word(lParam)
     if find(wParam,socks) then
        if msg = FD_READ and error = 0 then
            dat = alloc(1024)
            size = tcp_recv(wParam,dat,1024)
            if size > 0 then
               buffs[find(wParam,socks)] &= peek({dat,size})
            end if
            free(dat)
        elsif msg = FD_CLOSE then
            do_proccess(buffs[find(wParam,socks)])
        end if
     end if
     return 0
end function
setWinMsgHandler(download,WM_SOCKET,routine_id("onWM_SOCKET"))

This is just a sniplet, and not fully working code.  But this shows how
you can do simultanious downloads.  wxEuphoria should be very similar,
and easy to implement.  Just remember, when you go to add a download to
"Query", you need to add the Socket that it was created with, and the
buffer space, in which to store the data, till the transmission is complete.

And when the transmission is complete, remove the socket, and buffer data,
so that you don't get memory leakage.

> Thanks for your help. In the next few days, I will be trying the 
> wxEuphoria socket
> functions again and certainly use your advice.
> 
> Thank-you,
> Bruce Douglas

My apologizes for the double post, Rob, we seriously need a Preview
function, so that way, we don't have things like this happening, especially
when we're tired. :P

Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...

10. Re: Threads vs Processes

• Posted by Patrick Barnes <mrtrick at gmail.com> May 05, 2005
• 504 views

On 5/4/05, Juergen Luethje <j.lue at gmx.de> wrote:
> >> I would like to avoid using the Windows API calls since I would like m=
y
> >> programs to still work in Linux.
> >>
> >> Is there a way to implement this without threads?
> >
> > Yes, there is.
> > Unfortunately, not within Euphoria itself.
> >
> > There's a library called IPC that allows you to make procedure and
> > function calls across euphoria programs. Procedure calls are
> > asynchronous, function calls are synchronous.
>
> You probably mean "ipc.zip" by Thomas Parslow, don't you?
> It's only for windows.

Well yes, it's only for windows. I've been meaning to start working on
an inter-process communication system based on sockets, so it'll be
cross-platform. Should hopefully be able to scale up to any computer
on the subnet too, so that'll be interesting.

However, I'm a bit snowed under with work at the moment, so it might
take a while.


--
MrTrick
----------