Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



--- Martijn van Oosterhout <kleptog@xxxxxxxxx> 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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
       message can get through to the mailing list cleanly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux