Hi List,

I have a weird problem. the "fpWrite" is too "slow" for FPC code. When I have the same exact code in C that writes a big amount of buffers of the same size with the same content. It seems that the fpWrite is way too fast, and the can't handle another call in the loop, and I need to slow down the loop using usleep.
At the beginning I thought that it was a problem with fpWrite, so I created my own binding, but still the problem is the same.

Except then the fact that it seems that FPC is much faster the GCC, any other ideas for such a behavior and what might be the reasons for it ?

A POC for such code btw, can be as follows:

Pascal:
...
while not EOF(f) do
  begin
      readln(f,s);
      fpwrite(f2, S[0], length(S));
  end;
....

C:
...
while (! feof(f)) {

  s_size = fread(f, s, MAX_BUFFER);
  write(f2, s, s_size);

}
...

This is a POC I wrote just here for the email, but the actual code that I'm talking about is 100% equal with the content and the amount of data that was read.

Thanks,
Ido

What error do you get? Lastly I had something similar with fpc writing to fast to a non-blocking stderr channel. I haven't had time to do for my code, but if you get "ressource temporartily unavailable"-like errors switching the file to blocking mode might help.

Something like

fcntl(fileno(stderr), F_GETFL) & O_NONBLOCK

or the pascal equivalent should do.

HTH,
Marc

I'm getting -1 from fpWrite for a "long" period of time, like 6-7 loop returns before it can continue getting the my next content, only to have the same problem repeated...

HTH, Marc

Ido

This is not about Pascal or C. The code is only calling the linux kernel. You can use strace to analyze this kind of issues.

Peter

Have you tried getting the os error?

GetLastOSError() from sysutils is your friend, otherwise gdb does a good job in catching exceptions early and backtracing.

Marc

Check errno, an if it is EAGAIN, try... again :-)

Maybe some libc versions do this in their libc (as opposed to kernel) read/write versions already.

I found a scary thing with fpOpen after using strace: It adds me the flag O_LARGEFILE. Another issue that was not the same as the C code, and now it seems to solve the problem completely was that I opened a device as a non blocking, while the C was blocking. removing the O_NONBLOCK solved the problem completely. And yes strace showed me the EAGAIN flag :(

BTW it is a C vs Pascal thingy... Linux and libc are written in C... ;)

Thank you all for the help,

Ido