I would base the choice of IPC mechanism on what other requirements there are:

• Should the workflow elements be able to run on different machines than the GUI? If so, I would look away from named pipes or unix domain sockets, and look at a network based messaging mechanism like TCP, UDP, syslog, or even SMTP.
• Does the GUI have file system access to all directories where the workflow elements run? If so, a simple log file for each element might be enough. Reconfiguration etc. would then require signals, if the OS provides an implementation.
• How critical is reconfiguration over transactional stability? If reconfiguration is less important than finishing a transaction, you can get away with having the main loop checking for a configuration change and alternatively processing the next item. That way, you will always process an item completely using a single configuration. Also look into versioned workflows as Workflow discusses them.

As for the choice of mainloop, I would really try to avoid introducing POE or Glib or any other complex mechanism into a workflow element. Try to keep these as small, self-contained external programs. This makes them easily testable and also forces you to define clear boundaries and clear input and output specifications. Having multiple external processes also makes it very easy to scale up your process over more machines or CPUs.