Re: Function written in C, hangs on one machine and not another...

--- Martijn van Oosterhout <kleptog@svana.org> wrote:

> On Fri, Oct 28, 2005 at 06:38:29AM -0700, CG wrote:
>
> Umm, what *are* you trying to do? Is this running in the backend?

Yes, running on the back-end. I'm trying to utilize Adobe's FDF toolkit to
parse the FDF files stored in my database. They distirubte a C-Library that can
be used to parse FDF files.

> Firstly, depending on the saize of param_1, the write will block
> because it can't write all of it (usually PIPE_BUF). Perhaps recent
> kernel versions have changed to make it so no data is accepted until a
> reader appears even if the data is smaller than that.
>
> Since apparently you want the read to happen in the same process as the
> write, you've just deadlocked yourself. The write won't happen till
> someone reads, and the read won't happen because you're stuck
> writing...

So it might be a kernel thing. What is different when the function is called
from within PostgreSQL that is different that the function being called in a
standalone program?

> Finally, this is insane, why would you want to change STDIN?

Insanity? I agree completely. The major issue is that the FDF Toolkit has only
one function for reading in FDF Data:

/*
  FDFOpen: Reads an FDF file into memory. Client should call FDFClose() when
  the FDF is no longer needed. Parameters:

  - fileName: Complete pathname (in Host encoding), or  "-" to read from stdin.
  - howMany: If fileName specifies stdin, then howMany should indicate the
        number of characters to read. Otherwise, it is unused. In a web server
        environment, this is available as the value of the CONTENT_LENGTH
        environment variable. In some servers executing cgi-bin scripts, if the
        script tries to read stdin until an EOF is reached, the script hangs.
        Thus this parameter.
  - pTheFDF: If FDFOpen() returns FDFErcOK, then pTheFDF will point to an
    FDFDoc, which is needed for most other calls in the API.
  - Error codes: FDFErcBadParameter, FDFErcFileSysErr, FDFErcBadFDF,
        FDFErcInternalError
*/
FDFLIBAPI FDFErc FDFOpen(const char* fileName, ASInt32 howMany, FDFDoc*
pTheFDF);

There's no other way to load data into the toolkit! (Can you /feel/ the
insanity?)

Does this give you any more insight into an alternate method of getting this
thing done?





__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs