in reply to Re: non-blocking TCP/IP client object using callbacks
in thread non-blocking TCP/IP client object using callbacks

No, I'm not really afraid of socket programming either. I failed to explain myself is all. I had actually planned on having to clarify. I'm just not very good with the english... Meh.

The question is really: What's the best way to implement a client object that can read and write to a socket, but that passes control back to the caller, and that passes received lines back to the caller via a set of function callbacks.

So far, I rather think I'll end up doing this with IPC and a fork() because it'll be the most portable. Well, I'm not 100% on that. Does IPC and fork even work on windows? I wouldn't know. But I do know that threads don't work everywhere.

  • Comment on Re: Re: non-blocking TCP/IP client object using callbacks

Replies are listed 'Best First'.
Re: Re: Re: non-blocking TCP/IP client object using callbacks
by zby (Vicar) on Jul 22, 2003 at 12:40 UTC
    Perhaps the caller could periodically pass the controll back to the socket listener? Thus you would not need the parallelism whis is allways a bit tricky.
[reply]
      That won't probably work quite right. Since the caller will probably be Curses, or GTK or something, control needs to be with the UI nearly all the time.

      If you ever got stuck in a blocking getline or something, the UI would be very irritating. Anyway, I had considered that. But if you want to release a module that other people are likely to use... then you have to do the hard work for them. :)

      I just asked about this here, because I wanted to make sure what I was doing was ... a good way to do it.

[reply]
        How about an UI with callbacks for communication? Like Tk::fileevent in Tk.
[reply]
[d/l]

In Section Seekers of Perl Wisdom