I (against my better sense) thought it was a good idea to request over 3 million cobblestone into another mod's autocrafter with the use of a Mk. II Request pipe. Sure it worked out pretty well, but unfortunately it seems to have caused an unexpected issue with the rest of my network.

You see, sometimes when I try to request things, it will deduct the items properly from the menu but they never come. Checking the inventory source shows that the items are still there.

It may have something to do with the fact that everything is funneled through a single ME interface, but other than that I have no clue.

And now I have to manually withdrawal items from my ME system because there doesn't seem to be an cancel button for my absurdly (and admiringly foolishly) large request. I COULD wait it out, but honestly at 3 million, it's going to be a few days before that finishes.

Next time, use an MK3 :D

I just checked... It's actually 200 million.

This is going to take a few years...

Seems like your "Other Mods Autocrafter" is incredibly slow...

breaking a crafting pipe drops all requests going to it. -- it's a
localised emergency fix ;)

On Mon, May 4, 2015 at 9:27 PM, Bitterholz [email protected] wrote:

Seems like your "Other Mods Autocrafter" is incredibly slow...

—
Reply to this email directly or view it on GitHub
#671 (comment)
.

“Getting information off the Internet is like taking a drink from a fire
hydrant.”
– Mitchell Kapor

It is intended that provider pipes (e.g. on an ME interface) work serialized, because it's logical. As long as one request task is running on a provider pipe/module it does have to finish that task before beginning any new task. Same goes for any other pipe/module basically.

@theZorro266 I think you meant Synchronised, And jes that the best way of doing it. Otherwhise you would have different request Interfere with each other. Containers would be Drained when there is still a request going, wich would cause huge Problems.

No, I meant serialized as opposed to work on multiple tasks at the same time which is similar to parallel work. I do not say that it is the best way of doing it, but I say that it is the way that we do it now.

Thats actually syncronized, Just heared that Today in my Programming Tutorium at University.

And Yes its actually the best way to do it, It would create aborted Requests and unfinishable Crafting/endless wait if the Provided ressource Operations weren´t Synchronized. Wich is why having the Provider locked if a request is going is the best way.

I am not going to discuss why I mean and say serialized,
but for the sake of the issue I do not think that it is the best possible way it works right now. Not saying that we should parallelize it, but instead reorder by importance when a new request comes in.. Like a CPU scheduler does for cores basically