http job doesn't suspend in kde4 and k- vs qprocess

[koos vriezen]

2007/10/16, Thiago Macieira <thiago at kde.org>:
> Em Tuesday 16 October 2007 12:13:19 koos vriezen escreveu:
> > The code is in
> > branches/work/kde4/extragear/multimedia/kmplayer/src/kmplayerprocess.cpp
> > But it's about code that worked in kde3, like
> >
> >   void NpStream::slotData (KIO::Job*, const QByteArray& qb) {
> >         pending_buf = qb;
> >         if (qb.size()) {
> >             job->suspend ();
> >
> > which stopped this job from pushing data.
>
> Suspension isn't immediate. There may be data that is already queued for
> emission and will be handled before the suspend takes effect.

Ok thanks, so indeed the behaviour has changed a little then.

> > > > Another thing I'm watching is the replacement of k3process to
> > > > qprocess. While k3process is lightweight in passing the data to the
> > > > final stdout, qprocess copies the data. So now I'm wondering if I
> > > > should use popen or something else and use socketnotifiers instead.
> > > > Actually what I really would like is not the data signals itself, but
> > > > a unix domain socket where the data could be read from directly from
> > > > the slave, as I need it to send to another application anyhow, that
> > > > application could read it directly instead. Any other signal, should
> > > > still be signal'ed though.
> > > > Any advice on the matter would be appreciated.
> > >
> > > Don't use popen and don't use socket notifiers. Anything else is
> > > acceptable. I did not understand what you meant about QProcess.
> >
> > What is the issue with socketnotifiers? k3process uses these.
> > (sometimes I get 100% CPU usages and notice constant QSocketNotifier
> > events, I wonder if this might be related)
>
> K3Process is Unix-only.

I see
So  if I understand you correctly above, popen and QSocketNotifier
should not be used because it's doesn't work on Windows. Or are there
other issues you know of that might explain the 100% CPU usage I get
sometimes?
(It looks like a fd corruption, that constantly triggers write events,
but I'm not sure yet)

Br.
Koos