[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Serious DCOP problem.
From:       Michael Matz <matz () ifh ! de>
Date:       2000-12-21 9:58:00
[Download RAW message or body]

Hi,

On Thu, 21 Dec 2000, aleXXX wrote:
> >> I ran into a rather serious problem with DCOP.
> >>
> >> What seemed to have happened is the following:
> >>
> >> knotify did a system("aplay somefile") and got stuck on that for some
> >> reason. As a result knotify didn't handle incoming DCOP request any more.

knotify should fork() before doing a system(). (Every program should do
that if the system() call doesn't need to be synchron) And in the
sub-process doing the system() an alarm() should be set. OK, this doesn't
solve the design problem in DCOP, but would help here.

> >> This caused the DCOP server to lock up on a write() call as part of a
> >> ICESendMessage (probably after it's buffer filled up with other requests).
> >> Result: a total lockup of the desktop.
> >>
> >> It's unacceptable that the DCOPserver brings down the entire desktop due
> >> to one hanging application!!!!
> >
> >Agree. Any ideas how to solve this?

A "_IceTransSetOption(iceConn->trans_conn, TRANS_NONBLOCKING, 1);" is a
first step. Then wrap each IceSendData() to test for iceConn->io_ok
afterwards. If it's 0, it means, the message wasn't send correctly or
completely. errno might contain EAGAIN if it broke because of
non-blockyness (so we can differentiate between real error and blocking),
but only if no registered ICE error handler itself sets errno. There is no
way in libICE to get hold of the number of bytes successfully sent. So we
either would need to reimplement some libICE functions, or a way in DCOP
to resent messages completely.

> select(fd,0,writeFDSet,0,&tv) before sending ?

This doesn't guarantee that a write(fd,buf,10000) wouldn't block (if fd
isn't non-blocking).


Ciao,
Michael.

[prev in list] [next in list] [prev in thread] [next in thread]