New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parallel backend causes high CPU load #2056

Closed
michaelrsweet opened this Issue Oct 26, 2006 · 6 comments

Comments

Projects
None yet
1 participant
@michaelrsweet
Collaborator

michaelrsweet commented Oct 26, 2006

Version: 1.2.5
CUPS.org User: twaugh.redhat

The parallel backend opens the device node with O_WRONLY, but then calls backendRunLoop with use_bc=1, causing it to try reading from the file descriptor. Of course this fails, but unfortunately it can produce busy-looping when the printer is off or busy.

Fix attached.

@michaelrsweet

This comment has been minimized.

Collaborator

michaelrsweet commented Oct 26, 2006

CUPS.org User: mike

Actually, we don't want to do it this way, but instead keep track of the open mode so that we can support bidi whenever possible.

I'll post a new patch that does this later today...

@michaelrsweet

This comment has been minimized.

Collaborator

michaelrsweet commented Oct 26, 2006

CUPS.org User: mike

The attached patch should do the right thing... Let me know if you still have problems..

@michaelrsweet

This comment has been minimized.

Collaborator

michaelrsweet commented Oct 27, 2006

CUPS.org User: twaugh.redhat

It fixes the high CPU load, but unfortunately Linux seems to do this:

select(5, [0 4], [], NULL, NULL) = 2 (in [0 4])
read(4, <unfinished ...>

i.e. select() says it's available for reading but read() blocks. I think it might be best to set use_bc=0 for Linux in the parallel backend.

@michaelrsweet

This comment has been minimized.

Collaborator

michaelrsweet commented Oct 27, 2006

CUPS.org User: mike

Sigh... Please report this as a bug upstream to the kernel developers? Thanks!

For now we'll just disable the O_RDWR open on Linux; other platforms don't have this problem...

@michaelrsweet

This comment has been minimized.

Collaborator

michaelrsweet commented Oct 27, 2006

"cups-parallel-busy-loop.patch":

--- cups-1.2.5/backend/parallel.c.parallel-busy-loop 2006-10-26 14:46:38.000000000 +0100
+++ cups-1.2.5/backend/parallel.c 2006-10-26 14:50:46.000000000 +0100
@@ -264,7 +264,7 @@
lseek(print_fd, 0, SEEK_SET);
}

  • tbytes = backendRunLoop(print_fd, device_fd, 1);
  • tbytes = backendRunLoop(print_fd, device_fd, 0);

if (print_fd != 0 && tbytes >= 0)
fprintf(stderr, "INFO: Sent print file, " CUPS_LLFMT " bytes...\n",

@michaelrsweet

This comment has been minimized.

Collaborator

michaelrsweet commented Oct 27, 2006

"str2056.patch":

Index: parallel.c

--- parallel.c (revision 6063)
+++ parallel.c (working copy)
@@ -88,7 +88,8 @@
options; / Pointer to options /
int port; /
Port number (not used) /
int print_fd, /
Print file */

  •   device_fd;      /\* Parallel device */
    
  •   device_fd,      /\* Parallel device */
    
  •   use_bc;         /* Read back-channel data? */
    

    int copies; /* Number of copies to print /
    size_t tbytes; /
    Total number of bytes written /
    struct termios opts; /
    Parallel port options */
    @@ -188,8 +189,16 @@

    do
    {

  • if ((device_fd = open(resource, O_WRONLY | O_EXCL)) == -1)

  • if ((device_fd = open(resource, O_RDWR | O_EXCL)) == -1)
    {

  •  device_fd = open(resource, O_WRONLY | O_EXCL);
    
  •  use_bc    = 0;
    
  • }

  • else

  •  use_bc = 1;
    
  • if (device_fd == -1)

  • {
    if (getenv("CLASS") != NULL)
    {
    /*
    @@ -264,7 +273,7 @@
    lseek(print_fd, 0, SEEK_SET);
    }

  • tbytes = backendRunLoop(print_fd, device_fd, 1);

  • tbytes = backendRunLoop(print_fd, device_fd, use_bc);

if (print_fd != 0 && tbytes >= 0)
fprintf(stderr, "INFO: Sent print file, " CUPS_LLFMT " bytes...\n",

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment