i originally replied to the from address, but it bounced. i'll put it to the
list, maybe he'll get it there, maybe someone else will find it enlightening
but i dobut it.
-rm
bobo@xxxxxxxxxxxxxxxxxxxx said:
>> what are you trying to acomplish? i won't say that signals aren't the way to
>> go, but there probably aren't a lot of cases where they are. i'll play around
>> with this some to see if i can find any problems, but i don't forsee there
being any. if you give us an idea of what you're trying to do we'd be in a
better position to help you figure out a way to do it.
>>
>> -rm
>
> Hi,
>
> i am working on an application, which is mainly a gtk2-gui that forks a
Frontier::Daemon process (which is an http-server, listening for xml-rpc
requests). When the server-process receives a certain RPC, the process shall
> notify the gui-process.
gtk plug/socket may be one possible solution for your needs. another may be i
threads (though there's much more to deal with there) there's examples of both
methods (plug.pl, socket.pl/thread_usage.pl) in the gtk2-perl examples
directory. the plug socket route is probably preferable as ithreads are not
enabled on a lot of perl installs.
> First, i thought I could realize the communication by sending a SIGUSR1 to
the GUI, but now, i think I'll let the child process (the http server) write
something to a pipe, which is watched by the Gtk2::Helper module in the GUI.
you're probably better off working withint the frameworks that perl/gtk2-perl
give you. if you go the ithreads/perl route then Thread::Queue is your friend.
-rm
|
